1с неверный первый параметр ссылка в функции общегоназначения значениереквизитаобъекта
Печать документов для контрагента из справочников Контрагенты, Договоры с контрагентами, Соглашения об условиях продаж, Договоры кредитов и депозитов. Документы печатаются на основе шаблона Word с установкой параметров [Параметр]. Второй вариант печати из обычного макета (Табличный документ) с установкой параметров. Можно использовать для печати таких документов как Договор, Дополнительное соглашение, Информационное письмо, Договор займа.
Обработка выполнена в виде ОбработкиЗаполнениеОбъекта, потому что для справочников Контрагенты, Договоры с контрагентами, Соглашения об условиях продаж нет процедуры печати в УТ 11.
После добавления обработки в Дополнительные печатные формы и обработки, обработка автоматически добавит список всех печатных форм в соответствии с названиями и синонимами макетов.
При нажатии "Выполнить обработку" и далее "Название макета шаблона" откроется заполненный Word.
Шаблоны Word необходимо добавить в макеты обработки. Названия макетов будут соответствовать идентификатору печатной формы, а синоним макета названию печатной формы в интерфейсе 1С.
Если использовать макет Табличный документ, тогда откроется обычная печатная форма 1С.
В качестве примера имеется несколько шаблонов макетов, и макет с названием Шаблон для вывода полной таблицы параметров в базе, предназначенный для тестирования.
Автоматически создаются реквизит "Основание" для справочника Контактные лица и два значения "Устав" и "Доверенность" для подстановки в договор. Ответственное лицо для договора выбирается контактное лицо у которого стоит роль "Руководитель".
ОГРН печатается из реквизита контрагента "ОГРН", реквизит создается автоматически.
Если Контрагент является физическим лицом, паспортные данные необходимо добавить на странице "Документ удостоверяющий личность".
Для организации необходимо указать реквизит "Каталог" для сохранения документов по указанному адресу, реквизит создается автоматически.
Ковыряя одну конфу от Раруса, обратил внимание, что очень много параметров процедур и функций в общих модулях описаны с использованием ключевого слова Знач. Такое описание делается даже в тех случаях, когда 100% с данные только читаются (т.е. исключено изменение объекта).
Подумалось следующее. А не фича ли это?
Ведь Знач (в случае передачи ссылки) на уровне СУБД по сути одним запросом выберет копию объекта и передаст в процедуру/функцию, где уже можно спокойно с ней работать, без дергания сервера мелкими запросами при обращении к свойствам объекта по ссылке.
Прав ли я или тут закопан какой-то другой смысл?
В-четвёртых, использование ключевого слова Знач при объявлении параметров процедур и функций. Дело в том, что при клиент-серверном взаимодействии это ключевое слово значит совсем не то, что при работе внутри одного компьютера, клиентского или серверного. Когда мы используем Знач при объявлении параметра серверной процедуры и вызываем её с клиента, это означает, что значение этого параметра обратно на клиент не приедет. Если же мы не устанавливаем Знач, а стандартно так и есть, то происходит следующее. Допустим, мы вызываем серверную процедуру и передаём в неё массив. Предположим, что на клиенте мы даже не собираемся потом этим массивом пользоваться. Он просто был параметром и на самом деле нам не нужен больше. Но когда серверный вызов закончится, массив будет упакован в XML или JSON (на веб-клиенте), и уедет обратно на клиент. Понятно, что это совсем неэффективно. Поэтому если вам не нужно возвращаемое значение, переданное через параметр, пишите ключевое слово Знач у таких параметров. Конечно, если параметр Булево, Знач можно сэкономить и не писать. Но по сути это нехорошо.
(0) Я бы не стал конфу от раруса рассматривать, как объект для подражания. Смотрел УАТ, так в шоке был от увиденного.
Значит в клиент-серверном варианте, если передавать через Знач ссылку на, к примеру элемент справочника, то в процедуру/функцию все равно придет ссылка, а не копия объекта элемента справочника?
Первый - сугубо идеологический. Указывая "Знач" вы явно объявляете свое намерение сделать параметр строго входным (обязуетесь не изменять параметр)
Любой человек, который ваш код будет читать, может посмотреть на сигнатуру метода и сказать: "так, эти два параметра входные, а вот этот без "Знач" - выходной, он где-то в коде присваивается и в нем что-то возвращается". То есть, указывая знач, вы облегчаете чтение своего кода и явно объявляете намерения в сигнатуре метода.
Второй аспект - технический. При передаче чего-то на сервер, если параметр без слова "Знач", то платформа считает этот параметр выходным и при возврате на клиента будет обратно передавать его значение. Указывая Знач вы оптимизируете трафик.
а по поводу копии объекта, это вы не понимаете что такое ссылка. Ссылка это просто GUID. Ее можете передавать с сервера на клиент и обратно, никаких копий "объектов" не создается.
СправочникОбъект на сервер передать вообще нельзя, это мутабельное значение.
Когда вы пишете "А = Ссылка.Наименование" происходит запрос в СУБД и в память поднимается ВЕСЬ объект вместе со всеми табличными частями. Передавая ссылку на сервер вы передаете только GUID. Эти два процесса (запрос в базу и передача ссылки) вообще не связаны никак.
(11) А, ну понял. Меня просто СП сбил с толку.
Получается если мы передаем ссылку на элемент справочника, то без Знач передаем ссылку на ссылку, вернее указатель на ссылку. А со Знач само значение ссылки.
(12) %) Я Ничего Не Понял
Если мы передаем со Знач или без Знач ссылку, то мы передаем GUID. Ссылка в базе данных и Ссылка на объект в памяти это как бы разные ссылки, не находите?
Вот здесь будет переход с машины на машину (с клиента на сервер). Параметр передается "по ссылке". Поскольку это две разных машины, то у них никак не может быть общая память. Платформа здесь делает следующее:
1. Передает значение 0 на сервер (по сути делает копию переменной А)
2. На сервере устанавливается некой переменной значение 1
3. При возврате на клиента платформа помнит, что передача должна быть "как бы по ссылке" и присваивает в А значение, установленное на сервере.
Теперь, если поменять код и вместо &НаКлиенте написать &НаСервере, то будет следующее:
1. В метод ПоСсылке будет передан условный адрес переменной А, по этому адресу записано значение
2. В точке вызова будет видно, что А стало равно единице.
Я, собственно, к чему. Не думайте про ссылки, как про указатели. Если происходит переход с одной машины на другую, то в любом случае будет задействована сериализация туда и обратно. Слово Знач указывает на то каким должно быть НАБЛЮДАЕМОЕ поведение в коде. Технически это могут быть более сложные вещи.
(0) Знач не имеет никакого отношения к СУБД
(6) ИМХО там в большинстве случаев параметры передаются по значению, скорее передаче по ссылке является исключением.
Использование знач для ссылок приводит к созданию новой ссылки то есть другого обьекта с типом ссылка
(16) "Использование знач для ссылок приводит к созданию новой ссылки то есть другого обьекта с типом ссылка" - какие-нибудь подтверждения этому тезису есть?
В документации сказано, что агрегаты передаются всегда по ссылке.
(17) "По ссылке" означает, что если вы перезапишете переменную внутри функции, то она изменится и в точке вызова.
Если "По Значению", то в точке вызова останется то же значение.
Если передали "По значению" коллекцию, внутри метода вызвали Очистить(), то в точке вызова она тоже будет очищена. Вы не перезаписали переменную коллекции, а вызвали метод, который изменил внутренности объекта. Т.е. агрегат (коллекция) как бы ни передавался - если вы меняете состояние объекта - оно меняется везде.
Вот правда вы как школьники.
Это же основы программирования.
С Знач копия объекта создается в процедуре и там же умирает.
Без Знач- передается ссылка(и это может быть ссылка на объект с возможностью изменения) . Вот тут возможны варианты когда работать или не будет или не оптимально.
Вот не знаю как там внутре 1С, некоторые другие языки создают копию объекта только в момент изменения. Если вы понимаете о чем я.
Но на самом деле это не имеет значения.
Хотя изредка очень хочется, чтобы про типобезопасность и имьютабилити платформа "думала" сама.
В контексте ветки внимание, вопрос: зачем нужна такая функция:
На ИТС есть же статья "Передача параметров по ссылке и по значению при вызове процедур и функций"? Там всё подробно разжёвано.
Все мы знаем, что обращение через точку эту моветон, лишняя нагрузка итд, что все нужные данные надо доставать запросом либо, например, БСПшным ОбщегоНазначение.ЗначениеРеквизитаОбъекта(). А нахрена тогда вообще точка и в каких случаях ей пользоваться? Если конфа точно не будет под нагрузкой? Если лень писать запрос?
И самое главное, почему 1С не поменяет механизм работы точки?
>Если конфа точно не будет под нагрузкой? Если лень писать запрос?
Наверное, примерно так.
>И самое главное, почему 1С не поменяет механизм работы точки?
А есть идеи на что его менять? (кроме как сделать как в тонком клиенте - т.е. просто выкинуть)
(0) Выборка данных запросом через прокладку очень быстро становится медленнее, если нужно значительное количество данных объекта. При чтении через точку при первом обращении объект читается, а затем он некоторое время кеширован, и последующие обращения через точку быстрее любых прокладок.
(1) (2) Ну очевидно, что чаще нужно меньше половины реквизитов, а еще чаще 1-2. Поэтому через точку делать запрос на 1 указанный реквизит. Если нужно много реквизитов, то пишешь запрос.
(5) Во-вторых, это повышает скорость разработки и снижает затраты на сопровождение кода.
А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.
(0) Ошибка проектирования. Не заложили достаточно гибкости. Если хотя бы ТЧ и ЧЗ всякие не тянулись бы безусловно, уже было бы терпимо.
>почему 1С не поменяет механизм работы точки?
Поздно уже. Груз легаси кода неподъёмен.
(6) В других давно пришли к парадигме CQRS.
(0) "все нужные данные надо доставать запросом" - О ужас! В запросе тоже можно через точку доставать.
На самом деле разработчики платформы достаточно ленивы
запросто можно было это представлять синтаксическим сахаром вызова запроса
(9) 1С очень легко отбрасывает легаси-код. Вспомните как сильно отличаются редакции типовых конфигураций. Один переход на УФ чего стоит
(5) Запрос или ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Номенклатура, "Наименование") - красивее, чем Номенклатура.Наименование .
(8) Аналогично и про скорость разработки.
(12) Если получать реквизиты "поштучно" - это во многих случаях будет ещё хуже, чем получать объект целиком (накладные расходы на исполнение запроса съедят кучу времени).
(4) >> Если нужно много реквизитов, то пишешь запрос.
Как раз, если нужен одиночный объект почти полностью, то запрос писать не надо. Через точку самое то: накладные расходы на запрос будут сравнимы с чтением объекта в кэш.
Тоже не понимаю, почему 1С не поменяет алгоритм работы точки. Вернее, вижу только одну причину - низкий приоритет этой задачи.
Я точку иногда использую для упрощения кода, когда уверен что узким местом это не станет никогда и на увеличение общей средней нагрузки это тоже не повлияет. Т.е. не в цикле, на нетяжелых объектах и в нечасто запускаемых штуках. Оно как-то и нечасто приходится выбирать через точку или нет. Потому что обычно данные уже каким-то образом пакетно достаешь. А так, чтобы вот единичное обращение нужно было и приходилось решать через точку или нет - очень редко такое.
"Все мы знаем, что обращение через точку эту моветон" - я бы не был столь безапелляционным. К реквизитам представления объекта - можно обращаться.Не моветон? К реквизитам объекта, ранее уже прочитанного в кэш - не моветон? И куда деть обратную совместимость, которую хочешь не хочешь, а тащить приходится. Вырастили хвост собаке -теперь уже не отрубишь. А насчет запросов ради получения значений. запросы в цикле - тоже моветон :)
Само по себе "через точку" допустимо и иногда оправдано. Недопустимы только особо рукожопые варианты. Например, когда в цикле перебираются много документов с кучей реквизитов и толстыми ТЧ, и при этом разработчик херачит данные через точку. У получения данных "через точку" есть один существенный плюс - уменьшается объём кода и повышается его читабельность
(0) > И самое главное, почему 1С не поменяет механизм работы точки?
потому что всякие нубы не обладают пониманием того что точка это мета-конструкция которая позволяет писать коротко.
вОбъект2 = вОбъект1.Реквизит;
где:
.Реквизит - это инкапсуляция либо внутреннего запроса, либо получения данных из кеша значений.
внутренниый запрос обрабатывается уже скомпилированным кодом, которы быстрее кода на языке 1С.
+(24) тем самым мы имеем:
1. скорость работы
2. укороченную запись.
эти 2 вещи - бесценны для разработки.
(24) Да пусть "внутренний запрос" хоть четырежды скомпилирован. Если при этом тянется целиком объект - это нифига не очевидно и ни разу не оптимально в куче случаев. Причина у такой реализации была только одна - это было проще реализовать.
Хмм. имхо, есть ещё одна причина, когда считаю возможным отступление от канона и обращением к реквизитам "через точку": в угоду внесения минимально допустимых изменений в типовую версию.
(26) Предлагаешь не кешировать объект, а каждый раз в базу лазять?
Что тянут всё сразу - да, как-то не очень, хз и тч можно бы и не брать.
(31) Конечно. Сейчас так и делают, только через БСП. Точку и предполагается при единичных обращениях использовать. Если хочешь закэшировать объект в "старом стиле" - это очень легко делается явно. И при этом все наглядно и понятно.
(26) > Да пусть "внутренний запрос" хоть четырежды скомпилирован.
ну дык это разрабу решать, каким образом оформлять алгоритм. есть 2 пути: запрос и через точку, разраб сам и выбирает.
не скрою, тоже думал об этом, что иногда получаем избыточный набор реквизитов объекта. И как бы я программировал "экономичные выборки". Типа:
и мы влипаем в след. колизию: для "усеченного" объекта пришлось бы хранить в памяти словари усечения, т.е набор обрабатываемых реквизитов, тогда как для "неусеченного" объекта можно тупо использовать сингелтонные словари из метаданных. Это увеличит расход памяти на внутренний объект переменной, а их зачастую десятки тысяч.
Тут разрабам нужно выбирать тщательно.
(36) Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы. Вычитывание "мегатонного" объекта при попытке получения реквизита - это нефига не предсказуемое поведение. Чем больше неочевидной магии в системе - тем хуже "решает" средний разраб.
(39) Если мы точно знаем, что при точке объект целиком читается в память всегда - это очень даже предсказуемо.
(39) >> это нефига не предсказуемое поведение
Почему? Всё задокументировано. Новичок на эти грабли практически гарантировано наступает, способный хоть капельку думать осознает и запомнит.
(39) Я бы не парился насчет "среднего разраба". Как выучится, такой и продукт будет. Это не проблема фирмы 1С.
Дооооо. Конеееечно. Железный аргумент. Чтобы все было предсказуемо, нужно сначала выучить всю доку назубок. Так можно оправдать любую ересь. Главное, чтобы была задокументирована.
Только при наличии выбора любой вменяемый человек выберет из двух систем более предсказуемую. И в среднем на более предсказуемой системе будет совершаться меньше ошибок.
(41) "Новичок на эти грабли практически гарантировано наступает" - т.е. ты считаешь, что это норм? Вместо того, чтобы убрать грабли?
(39) > Чтобы средний разраб "хорошо решал", ему хорошо бы иметь максимально предсказуемое поведение системы.
т.е. документацию изучить.
В рекомендациях от 1С сказано что обращение через точку "позволяет создавать компактные запросы". И там не сказано что это моветон
(39) Оба два решения не очень, поэтому 1С оставила делать выбор разработчику.
Если отдавать через точку, только нужный реквизит, то это повысит читаемость кода, но может привести к тому, что разрабы вообще не будут способны понимать, что если обрабатываешь большой или потенциально большой набор объектов, то нужные данные лучше сразу выбрать запросом. Вместо этого возможно долбежка СУБД мелкими запросами в циклах, для получения одного реквизита объекта.
(60) особенно актуально когда тип - любая ссылка. Например поле регистратор. В обычном запросе можно ограничить выборку через выразить
+(50) Ну и не так уж трудно запомнить, что при получении реквизита ссылки через точку будет получен весь объект.
(50) О да. Лучше подождать, пока разраб в своей практике не споткнется о внезапное кэширование больших объектов. Очень педагогично.
У разраба с минимальным бэкграундом в чем-то еще кроме 1С обязательно возникнет в голове вопрос - что происходит при обращении через точку. И интуитивно предполагаешь как раз точечное обращение к БД вместо ковровых бомбардировок.
(52) Это запомнить несложно. Но запомнишь ты это только после того как споткнешься или вычитаешь в доке. Будь иначе - этого бы запоминать не пришлось вовсе. И не пришлось бы пользоваться костылями из БСП.
Не вижу больше смысла спорить об очевидных вещах.
(54) Тоже не вижу смысла спорить. Я просто не понимаю, почему нельзя запомнить простое правило и делать выбор в зависимости от ситуации.
(55) Какое еще "можно", когда "нужно"? Речь о том, что можно было лучше. Но "стокгольмский синдром", вероятно, мешает это осознать.
(45) Что ты считаешь граблями - кэширование? Или предлагается кэшировать объект частями?
Возможность прочитать объект в кэш и тысячу раз обратиться к его реквизитам без обращения к базе - реальная возможость, а не случайный баг.
(57) Возможное улучшение действительно может заключаться в разрешении частичного кэширования. И возможности указать (как в БСП), какие реквизиты потребуются в дальнейшем.
Но это сильно усложнит реализацию, особенно в части инвалидации кэша. Не факт, что оно того стоит.
(58) Можно было просто использовать Smalltalk, там нет точек при обращении к методам объектов. Тупо через пробел
(43) А теперь сравни количество 1Сников и количество остальных программистов для бизнес-приложений ;)
(45) Т.е. ты предлагаешь не читать объект? Тогда как будет обеспечиваться синхронность данных, полученных в разные моменты времени? Блокировкой с уровнем изоляции REPEATABLE READ? Вы реально считаете, что это ускорит работу нагруженной системы?
(59) Думаю, оно того НЕ стоит
(60) Речь же не про синтаксис, а про поведение платформы при обращении через точку(или даже через Объект["ИмяРеквизита"]) Я не вижу альтернативного и при этом лучшего в 100% случаев поведения чем есть сейчас.
(63) Можно было бы аккуратнее считывать тяжёлые реквизиты (строки неограниченной длины, ХранилищеЗначения) и табличные части. В остальном работает быстро.
PS: читать или нет ТЧ объекта при обращении "через точку" - это не вопрос. Как и предложение читать ТЧ позже при реальном обращении к ТЧ. Это не тема для обсуждения если вспомнить про многопользовательский режим работы и получение непротиворечивых данных. Если читать - то читать всё и сразу.
(0) Как раз ОбщегоНазначение.ЗначениеРеквизитаОбъекта(Ссылка, "Рекв") - это костыльный костыль. Никакой читабельности.
(68) >Если читать - то читать всё и сразу.
А чего не всю базу сразу? "Непротиворечивость" нужно рассматривать в контексте.
Вообще было бы логично для чтения всего объекта из базы использовать отдельный явный вызов, а через точку читать только конкретный реквизит, если мы весь объект не читали.
(73)
>> через точку читать только конкретный реквизит
тогда станет (очень распространенными) граблями:
Вопрос: зачем и чем это лучше текущей картины?
ИМХО здесь главный критерий логичности - соответствие документации, ну и вообще такое поведение (чтение целиком и кэширование) не выглядит абсолютным костылём.
(74) Перевернем ситуацию.
Предположим, что "главный критерий логичности" соблюден. И в документации написано, что по "точке" выполняется неявное обращение к БД за этим конкретным реквизитом.
Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
И тут кто-то предлагает "а давайте по первому обращению через точку неявно вытягивать весь объект?". Как далеко его бы тут послали? Я думаю - очень далеко.
(74) лучше уж повторный запрос, чем сразу тащить непонятно чего и в каком объеме. В оракле данные храняться не в строках, а в столбцах как раз исходя из того, что в большинстве случае данные требуются частично
ну сам код можно перед компиляцией препроцессировать неким оптимизатором. для одноточечной оптимизации - в принципе все не так уж и сложно (строится на кэш-структуре):
- для каждого из построенных соответствий объект-словарь препроцессировать код: перед первым использованием - присвоить по имени объекта структуру, в которую запросом (добавленным в тот же код или типа бсп-шного) - вытянуть только то, что упомянуто в словаре.
trdm что-то типа этого имел ввиду.
ЗЫ: ну, или заморочившись правилами оптимизации и обратимостью - сам код в конфигураторе оптимизировать - отменить, не замахиваясь на требования доработки платформы.
>>Все этим легко и прозрачно пользуются. Когда нужно пачку реквизитов получать - юзают запрос или явное ПолучитьОбъект().
Так же будет масса "специалистов" пишущих простыни "Рекв1 = Объект.Рекв1;. Рекв100500 = Объект.Рекв100500;" и удивляющихся что 1С тормозит.
Если бы мы говорили про систему написанную с нуля, тогда бы согласился: от неявного чтения через объектную модель можно вообще отказаться.
(76) >> лучше уж повторный запрос
Не лучше. Если мы говорим про средний объект(без сотен реквизитов и огромных ТЧ), то пара-тройка запросов будет не оптимальней чтения объекта целиком.
(69) Угу, и получить тормоза на ожидании блокировки. типа, хочешь изменить объект. но низззя! потому что его кто-то прочитал, например, для отчета. И так пока или сборщик мусора не уничтожит все ссылки на этот объект, или программист явно не разблокирует объект.
(72) Непротиворечивость для объекта нужна гораздо чаще, чем для базы.
(73) Т.е. ты хочешь получить кучу трудноуловимых глюков, которые не сможешь продемонстрировать исполнителю? Глюки будут возникать, когда объект будет меняться другим пользователем пока ты его читаешь.
(0) потому что это удобно. При обращении через точку - в кэш вычитывается весь объект. Последующие обращения через точку к этому же объекту вызывают обращения к памяти, а не к БД.
(81): чот вас колбасит. субъективное "удобство" аргументируете совершенно не относящимся к удобству способу ресурсозатратной реализации метода. єто нихера не удобно - это вынуждено.
(0) как то давно была большая дискуссия на эту тему на парнерском форуме, и завел ее, Тормозит, если я не ошибаюсь
в общем 1сники были не убедительны в дискуссии, как я помню
киньте сюда ту ссылку, кто найдет
По сути, чтение объекта целиком в кэш вместо реквизита, к которому обращаемся через точку - это вариант "упреждающего чтения (read ahead)" в райд-контроллерах. В подавляющем большинстве контроллеров есть возможность как включить эту возможность, так и отключить. А ещё, во многих реализациях есть "адаптивное упреждающее чтение", которое при чтении нескольких блоков подряд производит чтение еще нескольких после них. Что-то подобное можно было реализовать и в 1с. Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам - в четвертый раз читаем весь объект в кэш.
Если читать только один реквизит то может получится что читаешь контрагента, потом читаешь договор и между двумя чтениями кто то влезет и изменит объект. и получится что договор не соответствует контрагенту. А если читаем сразу весь объект такого никогда не случится. Объектный подход. Ты либо читаешь весь объект, либо ничего. У регистров сведений, например, нет объектов и обращение через точку не приводит к считыванию большого объема данных.
(85) >> Обратились скажем к трем реквизитам объекта без промежуточных обращений к другим объектам - в четвертый раз читаем весь объект в кэш.
В итоге четыре раза сходил в базу, а объект больше не понадобился. Бред же. Никакой логики.
Сейчас программист сам может решать когда и что читать и как это оптимизировать, а не рассчитывать на оптимизатор, который может не угадать.
(89) Вообще да. Если что-то объемное и критичное к времени выполнения - обычно это делается одним запросом, и в выборке уже готовые данные, обращаться через точку просто нет необходимости. А там, где время не критично - можно и через точку, зачем код усложнять?
(92): а вот хренасдва. по "ЗЫ" в (77) на коленке слепил скрипт для нотепад++ - работает, "одноточечная" оптимизация-откат кода.
(8) >> А те, кому нужна скорость любой ценой - пусть идут в Ассемблер и машинные коды.
Не прокатит. Я уже пробовал. Как только начинаешь делать что-то сверхсерьёзное, так сразу закапываешься и славливаешь тормоза на всём. Не реально на ассемблере писать учётные системы.
(82) ну вообще-то в это реализация классического Model-View-Controller в 1с.
Используется повсеместно.
И только грамотным 1сникам это кажется непонятным расколбасом.
А я всегда через точку обращаюсь, что бы было видно от кого эта переменная. Знаю, что это плохо и вредно, но так удобнее)))))
А ещё локальные переменные объявляю вначале процедуры через Перем и вношу описание, для чего и от чего они. Тоже ересь полная, но так удобнее и красивее. Зато минимизируются "зависшие" переменные
Думаю, в принципе это ООП-стиль - сразу получать весь объект. В этих ихних ООП не делают отдельных объектов для получения 1-2-3 полей основного объекта. Сразу тащится весь объект и уже из него получаются нужные поля
Добавляем внешний отчет в УНФ 1.6, Устанавливаем "тэги" для внешнего отчета в УНФ 1.6; устанавливаем "изображение образца" для внешнего отчета в УНФ 1.6.
Что-то не получается. Версия 1.6.17.174. Глобальным поиском не нашел даже вызов процедуры "ПриОпределенииНастроекОтчета"
(1) Процедура "ПриОпределенииНастроекОтчета" находится в модуле объекта почти каждого отчета в конфигурации УНФ, и аналогичную нужно создать в модуле объекта внешнего отчета.
Ага. Прошу прощения, в поиске стояли фильтры, поэтому сначала ничего не нашел. Разобрался, вот этот текст я у вас прозевал: "для начала нужно создать реквизит отчета "ЭтоОтчетУНФ" с типом булево".
Создал реквизит, теперь все работает.
Большое спасибо!
Ага, тоже на первом заходе пропустил про доп реквизит.
Сейчас "без гонки" внимательно перечитал и всё получилось!
Для справки: проверял сейчас на версии 1.6.9.36
В параметры регистрации для отчетов, команды передавать не обязательно, поэтому, если быть более кратким, то:
(7) Не совсем так, таблицу команд всё равно необходимо создать, но вот заполнять, действительно не обязательно.
В функции "СведенияОВнешнейОбработке", таблица как раз и создаётся.
Недавно кто-то спрашивал про вывод изображения образца, но правда после удалил комментарий. Всё же решил дописать статью, надеюсь кому-нибудь пригодится.
Релиз УНФ 1.6.18.145, платформы 8.3.15.1830.
Сделала внешний отчет с использованием ФормаОтчетаУНФ. При открытии через меню Файл-Открыть отчет отрабатывает "как надо".
Теперь нужно поместить отчет в расширение - добавила, туда же перенесла общую форму. Теперь при открытии ошибка :
Неверный первый параметр Ссылка в функции ОбщегоНазначения.ЗначенияРеквизитовОбъекта:
- Значение должно быть ссылкой или именем предопределенного элемента
: НСтр("ru = 'Неверный первый параметр Ссылка в функции ОбщегоНазначения.ЗначенияРеквизитовОбъекта:
: Результат = ЗначенияРеквизитовОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные);
: ЗначениеРеквизитаПользовательский = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ДопВариант, "Пользовательский");
Попробовала вынести во внешний отчет - ошибка такая же. Спасите помогите.
(12) Вы выбрали в качестве формы отчета общую форму: "ФормаОтчетаУНФ".
Попробуйте выбрать общую форму "ФормаОтчета".
(13) Форма открылась, но данные теперь неверно заполняются. Работа с параметрами периодов в этой форме отличается. Спасибо
Есть совсем простой способ. Возможно, кому-то подойдет.
Добавить теги и изображение внешнего отчета можно в режиме предприятия.
1. Добавляем внешний отчет
2. Через любой раздел открываем все отчеты, устанавливаем фильтр "Внешние", фильтр по разделу убираем
3. Вызываем контекстное меню нашего отчета, выбираем пункт "Настройки отчета"
4. Добавляем нужные теги (у меня - CRM и Продажи), описание, изображение
5. Теперь в разделах, указанных в тегах, в списке отчетов будет наш отчет с изображением
Минус этого способа - при обновлении внешнего отчета установленные выше настройки слетят и нужно будет их устанавливать заново.
Есть совсем простой способ. Возможно, кому-то подойдет.
Добавить теги и изображение внешнего отчета можно в режиме предприятия.
1. Добавляем внешний отчет
2. Через любой раздел открываем все отчеты, устанавливаем фильтр "Внешние", фильтр по разделу убираем
3. Вызываем контекстное меню нашего отчета, выбираем пункт "Настройки отчета"
4. Добавляем нужные теги (у меня - CRM и Продажи), описание, изображение
5. Теперь в разделах, указанных в тегах, в списке отчетов будет наш отчет с изображением
Минус этого способа - при обновлении внешнего отчета установленные выше настройки слетят и нужно будет их устанавливать заново.
Мы не консультируем по вашей конфигурации, поэтому мне физически не проверить ее у себя в тестовой базе, но как программист, я понимаю, что окно с ошибкой сигнализирует о незаполненности какого-то реквизита в базе .
Раньше он мог не проверяться, а после обновления (или сбоя — это тоже нельзя исключать) идет его автоматическая проверка, которая и выдает ошибку.
Я встречала такую ошибку в 1С:Отчетности, поэтому прошу вас, пришлите мне скрин карточки организации, чтобы в ней были видны банклвские реквизиты. Если это то, что было и там — мы это исправим.
Если нет, то придется вам открывать Конфигуратор (у меня подобной конфигурации нет) и мы вместе посмотрим, что в общем модуле Общего назначения в функции Значения реквизитов объекта передается, чтобы определиться, что программа хочет видеть заполненным.
Ошибки:
———————————————————————————
17.02.2021 12:37:40
Неверный первый параметр Ссылка в функции ОбщегоНазначения.ЗначенияРеквизитовОбъекта:
— Значение должно быть ссылкой или именем предопределенного элемента
: НСтр(«ru = ‘Неверный первый параметр Ссылка в функции ОбщегоНазначения.ЗначенияРеквизитовОбъекта:
: Результат = ЗначенияРеквизитовОбъекта(Ссылка, ИмяРеквизита, ВыбратьРазрешенные, КодЯзыка);
: КодСчета = СокрП(ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Счет, «Код»));
: КОСГУ = КЭКДетальныйСчета105(Организация, ИФО, КФО, Дата, Счет, ДтКт);
: Результат.КЭК = БухгалтерскийУчет.КЭКНоменклатуры(Параметры.Организация, Параметры.ИФО, Параметры.КФО,
: Возврат УправлениеМатериальнымиЗапасами.ПолучитьДанныеСчетаУчетаНоменклатуры(Параметры);
: ДанныеСчетаДляСтроки = УправлениеМатериальнымиЗапасамиВызовСервера.ПолучитьДанныеСчетаУчетаНоменклатуры(Параметры);
: УправлениеМатериальнымиЗапасамиКлиентСервер.УстановитьДанныеСчетаУчетаВСтроке(Строка, ПараметрыОбработки);
: ЗаполнитьДанныеСчетаВСтроке(ЭтотОбъект, НоваяСтрока, НЕ ЗначениеЗаполнено(НоваяСтрока.СчетУчета));
: ОбработатьВыборПодбораНаСервере(ВыбранноеЗначение,ИсточникВыбора.ИмяТаблицы);
: ОповеститьОВыборе(Структура);
: ПеренестиНоменклатуруВДокумент();
: Закрыть();
Добрый день,
у вас не одна, а целый набор ошибок. Поэтому давайте сначала сделаем так:
1. Почистите кеш 1С (обязательно!) — это очень важно: при обновлении могли поменяться процедуры и функции конфигурации, а кеш, из которого программа берет наиболее часто используемые данные, остался старым.
Его нужно удалить, тогда при входе в 1С автоматически создастся новый кеш. Правильный.
Посмотрите как это делать в 1С:
Очистка кэш 1С 8.3
.
2. Потом запустите 1С и проверьте — ушла ли ошибка.
Это тоже важно, потому что в тестировании программа найдет и покажет «битые» ссылки.
То, что вы показали на скрине строчку останова — неинформативно. Раз уж вы работаете с кодом конфигурации, вам нужно остановиться выше на самом условии, где формируется развился по исполнению кода и посмотреть: как именно передается — и откуда! ссылка, которая анализируется в условии.
Вообще посмотреть в параметры процедуры, где ошибка формируется, узнать, откуда передаются на исполнение эти данные — из какой процедуры.
И так вы по цепочке дойдете до причины.
Обычно, программист просто встает на процедуру исполнения, например, кнопки Подбор и проходит в Отладчике все шаги до появления ошибки. Тогда у него все данные на руках.
Если у вас не доработанная конфигурация — ПОЛНОСТЬЮ типовая, если обновление выполнял тот же человек, что и обычно, то первое, что вы должны сделать — почистить кеши 1С.
Если конфигурация дорабатывалась — без Отладчика вам причину будет не узнать.
3. Если все указанные выше действия не помогут, придется повторить обновление с копии повторно.
Но мне видится, что велика вероятность, что после чистки кеша и заполнения банковских реквизитов в карточке организации, проблема уйдет.
Спасибо) Разобрались сами. Был перенос данных и в карточках номенклатуры были отражены счет учета, которых нет в плане счетов. Применили обработку Групповое изменение данных. Ошибка исчезла
Читайте также: