[ Разбор вопросов ] Проектирование структуры регистров в задаче по работе с заказами клиентов на экзамене 1С:Специалист по платформе. Работа с характеристиками в СКД и программными модулями в расширениях

Разрабатывать эффективно возможно только за счет неуклонного и постоянного профессионального развития. Обязательно находим время на обучение! Итак, в сегодняшней подборке три интересных вопроса для разработчиков 1С: как исключить дополнительные реквизиты из списка доступных полей номенклатуры в настройках СКД; какие нюансы нужно учесть, проектируя структуру регистров в задаче по работе с заказами клиентов, на экзамене 1С:Специалист по платформе; что означает метод ПродолжитьВызов при работе с программными модулями в расширениях.

 

Вопрос № 1: Для каких случаев предусмотрен метод ПродолжитьВызов?

Как я понимаю, по сути вызов обработчика с аннотацией &Вместо, где в коде в конце будет написано ПродолжитьВызов() аналогично вызову обработчика с аннотацией &Перед  (и для &После тоже можно провести такую зеркальную аналогию). Не могли бы вы разъяснить, для каких вообще случаев предусмотрено использование ПродолжитьВызов() в методах с аннотацией &Вместо? Или смысл в том, чтобы была возможность вызвать стандартный обработчик посередине собственного кода? Но ведь и тут можно обойтись двумя событиями –  с &Перед  и с &Перед. В общем, мой вопрос – зачем вообще придуман метод ПродолжитьВызов() ? Если есть возможность, расскажите примеры, когда без метода ПродолжитьВызов() не обойтись?

Ответ

Дело в том, что для функций нельзя использовать аннотации &Перед и &Перед, а для процедур – можно. Поэтому чтобы существовала возможность не просто полностью переопределить функцию, а выполнить еще и исходный код из основной конфигурации, реализован метод ПродолжитьВызов() .

Если же рассматривать перехват процедур, а не функций, то метод ПродолжитьВызов() может использоваться “внутри” процедуры из расширения:

&Вместо("Процедура1")
Процедура Расш1_Процедура1(П1)
 //...
 ПродолжитьВызов(П1);
 //...
КонецПроцедуры

Это аналогично использованию аннотаций &Перед и &Перед.

 

Вопрос № 2: Как исключить доп.реквизиты из списка доступных полей номенклатуры в настройках СКД?

Вопрос по 1С:УТ ред.11. В типовых отчетах добавляются доп. реквизиты. Вопрос: как их исключить из отчетов? Например, существует 100 видов номенклатуры, к каждому из которых привязан свой набор доп. реквизитов – от 5 до 10. При изменении варианта отчета, где используется номенклатура, при раскрытии её, появляется список всех доп. реквизитов. Это жуткий тормоз. Можно ли сделать так, чтобы при отборе или добавлении поля, не выводились эти доп. реквизиты?

Ответ

Нет, поскольку это платформенный механизм – для справочника “Номенклатура” в конфигураторе настроены характеристики на уровне объектов метаданных. Поэтому они будут добавляться в список полей номенклатуры при работе с отчетами, динамическими списками, то есть в механизмах, базирующихся на системе компоновки данных.

Рассмотрите вариант переноса доп. реквизитов в обычные реквизиты справочника “Номенклатура”. Это должно увеличить производительность описанных действий.

Уточняющий вопрос

Раньше, помнится, надо было настраивать в СКД на закладке “Характеристики”, а сейчас, выходит, на табличную часть “Доп. реквизиты” программист повлиять не может?

Ответ

В 1С:УТ ред. 11 не требуется заполнять вкладку “Характеристики” в тексте запроса набора данных. Дело в том, что в этой конфигурации настроены характеристики на уровне объектов метаданных. Например, можно в конфигураторе обратиться к справочнику “Номенклатура”, в контекстном меню выбрать пункт “Характеристики”:

Дополнительные характеристики

Здесь указано, откуда система будет получать перечень характеристик и их значения.

СКД учитывает эту настройку, поэтому дополнительно прописывать характеристики в запросе не нужно.

Это пример разобранного вопроса из Мастер-группы курса
Профессиональная разработка отчетов в 1С 8.3 на СКД.

Описание курса и примеры видео

 

Вопрос № 3: Как правильно спроектировать структуру регистров в задаче по работе с заказами клиентов на экзамене 1С:Специалист по платформе?

Я не нашел ни в статье, ни в комментариях такой вариант регистров. Он по одному регистру позволяет делать отчет в любом разрезе. Например: Заказано, Привезли, Отгрузили:
 
Заказано = КоличествоДляЗаказа.Оборот
 
Привезли = КоличествоДляЗаказа.Оборот КоличествоДляЗаказа.Остаток
 
Отгрузили = КоличествоДляОтгрузки.Оборот.Оборот
 
Минус, как я понял в том, что приходится по регистру остатков брать обороты. Так? Зато можно легко строить отчеты по тому, сколько надо закупить и сколько надо отгрузить.

Регистры накопления

Дополню картинкой проведения по регистрам.

В моем случае надо сделать в один момент и расход и приход в одном регистре. Лучше делать два движения с нулем по одному из измерения или можно писать отрицательные числа. Как думаете? Математически все равно и плюс – нет лишних строк в таблице регистра.

Есть серьезный минус – невозможно нормально посчитать расход и приход из виртуальных таблиц. Все движения идут по расходу и в итоге оборот считается криво. Так делать нельзя – надо делать отдельными движениями приход и расход.

Заказы клиентов

(нажмите, чтобы увеличить картинку)

Ответ

Один регистр (минимальное количество регистров) – это вовсе не признак оптимального решения. И данный вариант – как раз из таких.

В этом варианте в регистр помещены ресурсы, относящиеся к разным показателям: количество заказанного и количество готового для отгрузки. Эти ресурсы используются в разных операциях поочередно, а не вместе, а значит, структура регистра будет “рыхлой” – с большим количеством нулей в качестве значений ресурсов. Это приведет к увеличению количества записей регистра и, возможно, к деградации производительности при обработке данных регистра.

Кроме того, объединенный регистр может ухудшить параллельность работы, тем более учитывая, что в данном случае разные ресурсы регистра могут использоваться поочередно в различных, не связанных друг с другом операциях.

Насчет “тяжести и значимости” данного недочета – многое зависит от конкретного экзаменатора. Кто-то может посчитать это не оптимальным решением и снизить оценку, кто-то может посчитать приемлемым. Но в любом случае я бы не рекомендовал такой вариант. Лучше все-таки разделить объединенный регистра на два отдельных регистра.

В целом решение рабочее, однако я не вижу принципиального отличия в лучшую сторону от предложенного в данной теме. Здесь также придется использовать обороты и получать некоторые показатели не напрямую, а вычисляя на основании других.

Движения нужно формировать так, чтобы они логически соответствовали производимой операции. Если поступление (или любое увеличение значения ресурса) – это приход. Если отгрузка (или любое уменьшение значения ресурса) – это расход. Отрицательные значения – это сторнирующие (отменяющие) операции: приход с минусом – это отмена прихода, но никак не расход; расход с минусом – это отмена расхода, но никак не приход.

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

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

Насчет того, будет ли снижена оценка за подобный вариант – однозначно сказать не могу. С одной стороны, числовые значения Ваше решение будет получать правильные, но вот логически это будет неправильным.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вход на сайт

Зарегистрироваться

Подтверждение регистрации будет отправлено на указанный e-mail.

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

Восстановить доступ

E-mail или логин

Ссылка на создание нового пароля будет отправлена на указанный e-mail.