1. Особливості запиту по документу.

Не використовуйте в межах одного запиту звернення і до реквізиту шапки документу і до реквізиту табличної частини (типу число). Тому що, напр., ф-ія запиту Сумма від цих цих реквізитів буде некоректно працювати в межах різних групувань. Не виключено і інші неточності.

2. Метод док-та НайтиПоНомеру(<Номер>,<Дата>,<ИдентВида>)

шукає документ в межах унікальності номера документа, тобто для параметра <Дата> для унікальності в межах року буде шукатись документ в межах року із переданої дати, в межах місяця - місяць і рік, якщо не унікальний - вся дата.

3. Обхід вкладених групувань в запиті

Стикнувся із такою особливістю

пока запрос.группировка(1)=1 цикл //товар
пока запрос.группировка(2,-1)=1 цикл //документи вибираємо по принципу LIFO (задом наперед)
 если такоеТоУсловие тогда //потрібно було проігнорувати всі інші наступні документи по даному товару
  прервать; //такий вихід із вкладеного групування не використовувати - збиває вибірку, зациклює на першому товарі у групуванні (1) і постійно вибирає по ньому документи
 конецесли;

використав додаткову зміну игнор по принципу

пока запрос.группировка(2,-1)=1 цикл
если игнор = 1 тогда продолжить; конецесли;
...

4. В случае, когда обход группировки по элементам (многоуровневого) справочника позиционируется на группе - обход следующих по вложенности группировок НЕ выполняется.

Единственный способ обойти эту особенность (например, получить все-таки список документов, двигавших регистр по всем входящим в группу справочника позициям) - это "спустить" группировку по справочнику на самый нижний (самый вложенный) уровень. Неочевидность подобных "плясок с бубном", а также невозможность такими "плясками" решить проблему в некоторых случаях (например, наличие в запросе более одной группировки по многоуровневым справочникам с необходимостью получения для групп таких справочников развернутых в разрезе других группировок данных) делает такую "особенность" вполне достойной для описания в качестве именно "бага".

5. Баг DBF-SQL (запросы+бух.запросы). При использовании в фильтре (отборе) списка значений результаты могут "вдруг" случиться разными.

Причина - некорректная обработка в SQL списков значений (в фильтрах запросов и бух.запросов), содержащих группы справочников.
Обход бага - если в SQL-версии в запросах и бух.запросах необходимо использовать фильтр по списку значений субконто типа "Справочник" - список значений должен содержать только элементы (не содержать групп).

прим.: в качестве срочного "костыля" при переходе с DBF на SQL можно использовать недокументированный метод объектов типа Запрос или Регистр - <Объект>.ВключитьSQL(0). Однако следует помнить, что этот метод очень сильно замедляет работу, и его рекомендуется использовать только в качестве "временного" решения проблемы.

6. Якщо маєте змінну модуля документу - ІНІЦІАЛІЗУЙТЕ ЇЇ ЯВНО. Інакше при пакетному проведенні неініціалізована змінна МОЖЕ бути не пустою, а зовсім навіть навпаки, може мати значення, що залишилось від проведення попереднього (!!) документу.

7. Метод Активизировать(<ИмяРеквизита>,<Режим>) працює тільки напередвизначених (системних) процедурах.

В документації про таке не згадується. Треба було в роздрібній торгівлі сканити товар, його артикул записувати в деякому реквізиті, шукати його і якщо знайшовся, то автоматом в діалозі вказувати його кількість і записувати в табличну частину. Знов активізовувати поле артикулу і процедуру повторяти. Реалізував цю активізацію за допомогою закриття і відміни закриття форми - процедура ПриЗакрытии.

щодо останнього, можливо, є якийсь інший більш "красивіший" (в плані оптимізації) перехід на інший товар?

Кожному багу - окрему тему.
Щодо п.1 - пам'ятаю ділив суму на кількість строк в документі

баги будуть публікуватися в першому пості

таке пробував, а потім взагалі відмовився від звернення до реквізита табл. частини (став не потрібним)

щодо п.3 таке зустрічали/реалізовували?

п.1 - не баг. всё вычисляется корректно - в соответствии со схемой запроса и обработкой его результатов. в баг это превращается при отсутствии понимания того, как работает запрос (в данном случае - при включении записей запроса, относящихся к группировке по строкам (или реквизитам строк), в состав группирующих записей по реквизитам шапки или документам). ошибка, свойственная не только запросам по документам, кстати.

п.2 - парафраз штатной документации ("описание встроенного языка", гл.12 - "Поиск зависит от выбранного в конфигураторе способа уникальности номеров (по месяцу, году и др.).").

п.3 - "описание встроенного языка", гл.33: "не следует прерывать последовательность просмотра временного набора данных (например, оператором Прервать;), если вы собираетесь использовать временный набор дальше или еще раз, т. к. в таком случае теряется точка позиционирования во временном наборе и продолжать просмотр невозможно" (в выводах к примеру в самом начале главы - кстати, пример сам по себе очень(!) полезен для понимания того, как работает запрос и обход его результатов).

Дополнение списочка. Особенность, в принципе понятная человеку, имеющему представление о том, как работает SQL-запрос (например). Но в связи с неочевидностью такой особенности, а также с отсутствием её описания в штатной (да и в нештатной тоже)) документации - вполне достойна описания в "багах". Так что - рекомендую:
В случае, когда обход группировки по элементам (многоуровневого) справочника позиционируется на группе - обход следующих по вложенности группировок НЕ выполняется.
Единственный способ обойти эту особенность (например, получить все-таки список документов, двигавших регистр по всем входящим в группу справочника позициям) - это "спустить" группировку по справочнику на самый нижний (самый вложенный) уровень. Неочевидность подобных "плясок с бубном", а также невозможность такими "плясками" решить проблему в некоторых случаях (например, наличие в запросе более одной группировки по многоуровневым справочникам с необходимостью получения для групп таких справочников развернутых в разрезе других группировок данных) делает такую "особенность" вполне достойной для описания в качестве именно "бага".

Баг DBF-SQL (запросы+бух.запросы).
При использовании в фильтре (отборе) списка значений результаты могут "вдруг" случиться разными.
Причина - некорректная обработка в SQL списков значений (в фильтрах запросов и бух.запросов), содержащих группы справочников.
Обход бага - если в SQL-версии в запросах и бух.запросах необходимо использовать фильтр по списку значений субконто типа "Справочник" - список значений должен содержать только элементы (не содержать групп).
прим.: в качестве срочного "костыля" при переходе с DBF на SQL можно использовать недокументированный метод объектов типа Запрос или Регистр - <Объект>.ВключитьSQL(0). Однако следует помнить, что этот метод очень сильно замедляет работу, и его рекомендуется использовать только в качестве "временного" решения проблемы.

щодо п.3.
...таке не стрічав, мабудь інтуітивно обходив.

Згоден з Cthulhu , якщо уважно придивитись - на "баг" жоден з трьох перших пунктів не тягне...
можливо доречно розділити тему на помилки & особливості

P.S.
Додаю до списку дуже бридку (і недокументовану) особливість : якщо маєте змінну модуля документу - ІНІЦІАЛІЗУЙТЕ ЇЇ ЯВНО. Інакше при пакетному проведенні неініціалізована змінна МОЖЕ бути не пустою, а зовсім навіть навпаки, може мати значення, що залишилось від проведення попереднього (!!) документу.
Типова ПУБ , наприклад цим нехтує.

тут і нюанси і особливості обговорюються, не всі знають SQL та і в документацію давно не дивились або так детально не розбирали
Щодо бух. запиту на SQL, помітив таке:
коли правив для клієнта логіку для додатка ОК, там запит по кореспондуючих рахунках прибутку - оборотне субконто ТМЦ. В клієнта цього субконто не було - древня конфа.

...
БИПроджиЕдиинщикам.ИспользоватьСубконто(ВидыСубконто.Контрагенты,,1,0);
...
БИПроджиЕдиинщикам.ИспользоватьКорСубконто(ВидыСубконто.ТМЦ,,1,0);
        БИПроджиЕдиинщикам.ВыполнитьЗапрос(НачГода(ДатаВКвартале),КонКвартала(ДатаВКвартале),"361,3771,3772,3773,3774","70,71,76",,3,"Месяц",1);    

        Если БИПроджиЕдиинщикам.ВыбратьПериоды() = 1 Тогда
            Пока БИПроджиЕдиинщикам.ПолучитьПериод() = 1 Цикл
                
                Если БИПроджиЕдиинщикам.ВыбратьСубконто(1) = 1  Тогда
                    Пока БИПроджиЕдиинщикам.ПолучитьСубконто(1) = 1  Цикл

    ТекКонтрагент = БИПроджиЕдиинщикам.Субконто(1);
    
                        Если ТекКонтрагент.ПлательщикНалогаНаПрибыль.Получить(БИПроджиЕдиинщикам.КонДата) = 1 Тогда
                            // это плательщик налогов на общих основаниях (не упрощенец = не единщик)
                            Продолжить;    
                        КонецЕсли;    
                        
                        ФизЛицо       = ?(ТекКонтрагент.ВидКонтрагента = Перечисление.ВидыКонтрагентов.ЧастноеЛицо, 1, 0);
                        Код              = ТекКонтрагент.ЕДРПОУ;
                        Наименование  = ТекКонтрагент.ПолнНаименование;
                        НаименованиеСокр     = ТекКонтрагент.Наименование;
                        
                        СуммаОБ = БИПроджиЕдиинщикам.ДО();
                        
                        Если СуммаОБ = 0 Тогда
                            Продолжить;
                        КонецЕсли;
                        
                        // из суммы взаиморасчетов вычтем сумму НДС, указанную в карточке товара
                        Если ОрганизацияПлательщикНДС = 0 Тогда
                        
                            СуммаБезНДС =  СуммаОБ;
                    
                        Иначе
                            
                            СуммаБезНДС = 0;
                            Если БИПроджиЕдиинщикам.ВыбратьКорСубконто(1) = 1  Тогда
                                Пока БИПроджиЕдиинщикам.ПолучитьКорСубконто(1) = 1  Цикл

так от в базі DBF (вивантажив із бази клієнта SQL і завантажив в DBF) цей запит пустий (що і логічно), а от в базі клієнта SQL заходить аж до вибірки корсубконто і аж в тому розрізі пустота. Такі от помідори.

ЗІ. Оновив перший пост. Вдячний за пости.

Именно так. Тело модуля выполняется при загрузке и компиляции формы документа / модуля документа. При групповом проведении (или даже при последовательном программном проведении документов одного вида) "движок" 1С "оптимизирует" этот этап - не перекомпилирует модуль, а использует тот, который уже был ранее скомпилирован и размещен в памяти. побочный эффект - в ранее скомпилированном и размещенном в памяти модуле "остаются в наследство" все переменные модуля со всеми "оставшимися" после предыдущего выполнения модуля значениями.
Встречается, увы, не только в ПУБ.

звідки такі відомості, можна лінк(и) чи Ви берете із досвіду об'єктно-орієнтованого програмування? цікаво про такі нюанси по 8.х дізнатися

инсайд. линков нет, что, впрочем, не странно в данном случае.
по 8.х - нет. пока просто неинтересно (а богатства багов, имеющего упоминания на просторах интернетов, не способствует появлению интереса).

зрозуміло, в більшості дізнаєтесь на форумах так як і я або в процесі практики

Якщо довідник має реквізит "Пиктограмма", то в формі списку довідника побачите цікавий результат.
Виявляється "Пиктограмма" - це також атрибут форми списку.
Платформа плутається, що саме показувати : реквізит , чи піктограму довідника

судячи з того, що в російських типових конфігураціях змінних модуля документів дуже мало, можна припустити, що існує рекомендація їх взагалі не використовувати.
від гріха подалі.

це системний атрибут, тому свої змінні потрібно називати інакше для уникнення плутанини

Использование ключевых слов встроенного языка в качестве названий объектов метаданных, реквизитов и переменных - крайне не рекомендуется. возникающие в результате несоблюдения данной рекомендвции баги вряд ли имеет смысл выделять каждый в отдельности. ну, мне так кажется.
А не-баги (полезные приемы и недокументированные особенности) - будем упоминать?..

Все так, але обставина, що зарезервований атрибут доступний для запису виглядає кумедно

ось ще якось надибав...
Якщо в регістрі є атрибут невизначеного типу, то в базі формату sql не працює конструкція в запиті

Условие(Атрибут В Список);

доводиться робити так

Условие(Список.Принадлежит(Атрибут)=1);

не працює також конструкція

Регистр.УстановитьЗначениеФильтра("Атрибут",Список,2);

P.S.
окреме питання : якого дідька робити в регістрах атрибути невизначеного типу... але це вже інша історія.

яких немає у файлі .als, що описує додаткові можливості 1С - постимо

в іншій темі

Ну вы б тогда либо дали ссылку на тему, либо сказали бы, что такой темы нету и в случае чего её нужно открыть

дозволяю відкрити

На выходных боролся с проблемой - не мог побороть.
Суть в следующем:
Внешний отчет, создает печатную форму. В модуле отчета описана процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Так вот, если диалог отчета не закрыт, то при клике на ячейке печатной формы вызывается описанная в отчете процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Если диалог закрыт, то вызывается описанная в глобальном модуле процедура ОбработкаЯчейкиТаблицы(..).
Для встроенных в конфигурацию отчетов вызывается описанная в модуле отчета процедура ОбработкаЯчейкиТаблицы(..), если она на самом деле имеется.
По моему, это баг платформы, побороть нельзя.

все ок

как мне кажется - это не баг. Когда процедура существует (форма открыта) - вызывается из формы, когда не существует (форма закрыта) - вызывается из глобального модуля. Я когда-то с этим тоже парился... Пришел к выводу, что нужно закрывать таблицу при закрытии формы. Тогда выполнение программы выглядит более понятным для пользователя.

Как раз вот это "Важно!" и не срабатывает в описанном мной случае.

Если форма закрыта, то 1с считает, что процедура не описана, т.к. ее нет в данный момент в памяти.

навіть якщо форма внутріншнього звіту чи обробки закрита, в цю форму відлагоджувачем (отладчиком) заходить в процедуру ОбработкаЯчейкиТаблицы?

Проверял отладчиком - не заходит, если формы нет на экране.

а в зовнішню обробку чи звіт, якщо він відкритий(а) також не заходить в цю процедуру?

Заходит. В том-то и прикол!

Почиталъ посты vadim007, переписавь хату на котя.

воно і повинно туди заходити, згідно документації (якщо форма звіту, обробки відкрита)

от так воно працює

vadim007
Это не баг, скорее недокументированная особенность. При открытии формы выполняется её компиляция и размещение в памяти, после чего выполняется тело модуля. Пока форма открыта (размещена в памяти) - из элементов её диалога доступны процедуры и функции модуля - это вопросов и стремлений что-то "побороть" не вызывает, верно?.. так вот, для "дочерних окон" - в частности, для окон с выведенными в них таблицами - механизм полностью аналогичен. Или более аккуратно сформулировать если, то вот:

Для таблиц, сформированных (и показанных) из модуля открытого экземпляра формы (любой!), предопределенные процедуры (в частности ОбработкаЯчейкиТаблицы) выполняется в контексте открытого экземпляра формы (из модуля этой формы) пока этот экземпляр формы открыт; иначе выполняются предопределенные процедуры (в частности ОбработкаЯчейкиТаблицы) Глобального Модуля.

И - извиниТЕ, но и для "встроенных" (включенных в метаданные) отчетов и обработок - это правило точно так же действует, т.е. если форму, из которой сформирована таблица, закрыть - предопределенная процедура ОбработкаЯчейкиТаблицы будет вызываться из глобального модуля (который компилируется и размещается в памяти во время загрузки конфигурации и "живет вечно" в рамках сеанса работы). так что это Вы, похоже, ошиблись просто.

Можно ссылку на первоисточник?

ответ здесь:

процедура описана до тех пор, пока открыта форма.

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

ещё вариант - таблица в режиме ввода данных.
только не ОбработкаЯчейкиТаблицы, а ПриВыбореЯчейки.

саме на зовнішніх я і тестував. в мене була потреба робити звіти без зміни та під різні конфігураціі. Поки форма відкрита викликається процедура з форми. Все логічно.

Я так думаю печатную форму нужно выводить в ФОРМУ ОБРАБОТКИ а не отдельно. И всё получится.

в такому випадку - прийдеться

ещё один довольно редко встречающийся, но очень неприятный баг.
при добавлении в подчиненный справочник с установленным отбором (с редактированием "в списке") эпизодически происходит дублирование внутреннего Id (того самого, по которому движок определяет "именно этот объект данных").

Еще одна особенность при обновлении измененных конфигураций. Давно сталкивался, и вот снова те же грабли:
Редактируем конфигурацию заказчика у себя. В неком документе имя реквизита ВидОплаты меняем на ФормаОплаты (так кажется более логично, т.к. он типа Перечисление.ФормаОплаты). Сохраняем конфу, приезжаем к заказчику, обновляем конфу. В окне "Объединение конфигураций" 1С честно предупреждает: ФормаОплаты: Объект добавлен; ВидОплаты: Объект удален, Возможна потеря данных!!!
Проверяем, правда-ли это - принимаем изменения, запускаем 1С, открываем документ - так и есть: реквизит ФормаОплаты у заказчика пуст!
Т.о., обновление в таких случаях нужно делать за два шага: непосредственно у заказчика изменяем имена реквизитов, если такое требуется, а затем обновляем конфу.

Это не баг, а правда жизни, т.к. 77, в отличие от 8, сравнивает объекты только по идентификатору, а не по внутренней ссылке НО если переименовать в основной базу УРБД, то в периферийной тоже переименуется.

Не баг. Как "отче наш".

1. Обновление конфигурации "объединением" - синхронизирует метаданные по наименованиям (идентификаторам).
Если объект метаданных конфигурации (с таким же именем, как в конфигурации-обновлении) не найден - создается новый со всеми свойствами, как в конфигурации-обновлении.
Если объект метаданных конфигурации (с таким же именем, как в конфигурации-обновлении) найден - все есго свойства изменяются в соответствии с конфигурацией-обновлением.

2. Обновление конфигурации "загрузкой" (измененной конфигурации) - синхронизирует метаданные по внутренним Id.
Если объект метаданных конфигурации (с таким внутренним Id, как в конфигурации-обновлении) не найден - создается новый со всеми свойствами (вколючая внутренний Id), как в конфигурации-обновлении.
Если объект метаданных конфигурации (с таким же внутренним Ид, как в конфигурации-обновлении) найден - все есго свойства (включая идентификатор-наименование) изменяются в соответствии с конфигурацией-обновлением.

ПОЭТОМУ.
Загрузка в рабочую базу данных результатов и доработок, выношенных "на стороне".
1. Снять копию рабочей ИБ (на локальный комп или в иное "отдельное место").
2. На локальном компе или в ином "отдельном месте" (см.п.1). Накатить "объединением" без сохранения - получить список переименованных реквизитов (которые при объединении обозначаются как "новые").
3. В копии рабочей ИБ - переименовать такие реквизиты "как надо" по списку, сформированному (копипастой или ручкой) при выполнении предыдущего пункта. Сохранить изменения.
4. На локальном компе или в ином "отдельном месте" (см.п.1). Накатить "объединением" (убедившись в отсутствии "неправильно добавленных" объектов метаданных, которые "на самом деле" нужно просто переименовать). Сохранить.
5. На рабочей базе данных. Обновить конфигурацию "загрузкой измененной конфигурации" из файла метаданных (1cv7.md), полученного при выполнении п.4.
6. Снять копию обновленной рабочей - на локальный комп/ноут разработчика. При необходимости - накатить на неё "объединением" те изменения и доработки, которые не вошли в новую версию рабочей ИБ (при выполнении п.4 были сняты галки). И начиная с этого момента для ковыряний/доработок использовать именно эту базу (старую можно спилить).


77 в отличие от 8 сравнивает и по идентификаторам, и по внутренним Id - зависит от желания программиста (если программист недостаточно профессионален - от воли случая).
УРБД, получая в согставе очередного обмена изменения конфигурации (в виде упакованного 1cv7.md в составе файла автообмена) - выполняет именно "загрузку измененной конфигурации".

Поддерживаю

ха. ещё. это все - для простейшего случая ("линейные" доработки одним программистом).
в случае коллективной разработки - ест нюансы. в п.4. (плюс сам регламент коллективной разработки).
если надо - могу (как время будет) сви взгляды на эту тему расшифровать более подроно, и, наверное, в необходимо зарегистрироваться для просмотра ссылки.

Уважаемые писатели данного топика!
Вам удобно все это писать и обсуждать в одной теме? Может создать подраздел где-то какой-то, или можно каждый полезный прием постить, например, необходимо зарегистрироваться для просмотра ссылки в отдельной теме. А то получается каша. И чем больше в этой теме постов - тем больше вся полезная информация этой темы превращается в кашу.

Можно отвечать прям тут, а после обсуждения, если оно будет, мы решим что делать и мусор уберем.

Vofka
Тогда уж необходимо зарегистрироваться для просмотра ссылки необходимо зарегистрироваться для просмотра ссылки.

Оживлю.
Общий реквизит документов типа "строка" неограниченной длины. Будучи НЕ последним в списке общих реквизитов (в дереве метаданных). В SQL-версии ведет к вылетам по внутренним SQL-ошибкам.
Отсюда - полезное универсальное правило:
На всякий случай. Всегда и везде. Общие реквизиты документов типа "строка" неограниченной длины в списке общих реквизитов дерева метаданных - смещать в самый низ списка.

цей баг виявлено на sql 2000 SP4 чи і пізніших версіях?

На всех.

маємо:

ит.ИспользоватьСубконто(ВидыСубконто.Контрагенты,СписокСубконто,1,0);
ит.ВыполнитьЗапрос(НачалоПериода,КонецПериода,"361", , ,1,"День","С");
Ит.ВыбратьСубконто();
Пока ит.ПолучитьСубконто() = 1 Цикл
ит.выбратьПериоды();
пока ит.получитьПериод()=1 цикл
...

С-П:

Що маємо реально, якщо по даному контрагенту за вибраний період не було оборотів, то в цикл по періодах не заходить - тобто напр., початкове сальдо по дт = 30 = кін. сальдо по дт=30.
Якщо ж

ит.выбратьПериоды(1);

в цикл по періодах заходить, навіть, якщо маємо ситуацію із прикладу.
Тобто, або під цим
мається на увазі, якщо були обороти за вказаний період по вказаному рахунку, а це

взагалі не правильно описано. Або я щось не так зрозумів із опису даного методу.
Хтось з таким зустрічався?
ЗІ. СписокСубконто - список на формі, в списку може бути і група.