Версия для печати темы (https://pro1c.org.ua/index.php?s=416a3b79c682aec1cf89d7ac4072e802&showtopic=8021)
Нажмите сюда для просмотра этой темы в обычном формате
Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7 _ Программирование в 1С Предприятие 7.7 _ Баги чи недокументовані особливості (ньюанси) роботи із платформою
Автор: mister-x 05.07.12, 21:06
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. Метод Активизировать(<ИмяРеквизита>,<Режим>) працює тільки напередвизначених (системних) процедурах.
В документації про таке не згадується. Треба було в роздрібній торгівлі сканити товар, його артикул записувати в деякому реквізиті, шукати його і якщо знайшовся, то автоматом в діалозі вказувати його кількість і записувати в табличну частину. Знов активізовувати поле артикулу і процедуру повторяти. Реалізував цю активізацію за допомогою закриття і відміни закриття форми - процедура ПриЗакрытии.
Автор: mister-x 25.07.12, 15:31
щодо останнього, можливо, є якийсь інший більш "красивіший" (в плані оптимізації) перехід на інший товар?
Автор: XBrut 26.07.12, 9:31
Кожному багу - окрему тему.
Щодо п.1 - пам'ятаю ділив суму на кількість строк в документі 
Автор: mister-x 26.07.12, 10:18
таке пробував, а потім взагалі відмовився від звернення до реквізита табл. частини (став не потрібним)
щодо п.3 таке зустрічали/реалізовували?
Автор: Cthulhu 17.08.12, 15:49
п.1 - не баг. всё вычисляется корректно - в соответствии со схемой запроса и обработкой его результатов. в баг это превращается при отсутствии понимания того, как работает запрос (в данном случае - при включении записей запроса, относящихся к группировке по строкам (или реквизитам строк), в состав группирующих записей по реквизитам шапки или документам). ошибка, свойственная не только запросам по документам, кстати.
п.2 - парафраз штатной документации ("описание встроенного языка", гл.12 - "Поиск зависит от выбранного в конфигураторе способа уникальности номеров (по месяцу, году и др.).").
п.3 - "описание встроенного языка", гл.33: "не следует прерывать последовательность просмотра временного набора данных (например, оператором Прервать;), если вы собираетесь использовать временный набор дальше или еще раз, т. к. в таком случае теряется точка позиционирования во временном наборе и продолжать просмотр невозможно" (в выводах к примеру в самом начале главы - кстати, пример сам по себе очень(!) полезен для понимания того, как работает запрос и обход его результатов).
Дополнение списочка. Особенность, в принципе понятная человеку, имеющему представление о том, как работает SQL-запрос (например). Но в связи с неочевидностью такой особенности, а также с отсутствием её описания в штатной (да и в нештатной тоже)) документации - вполне достойна описания в "багах". Так что - рекомендую:
В случае, когда обход группировки по элементам (многоуровневого) справочника позиционируется на группе - обход следующих по вложенности группировок НЕ выполняется.
Единственный способ обойти эту особенность (например, получить все-таки список документов, двигавших регистр по всем входящим в группу справочника позициям) - это "спустить" группировку по справочнику на самый нижний (самый вложенный) уровень. Неочевидность подобных "плясок с бубном", а также невозможность такими "плясками" решить проблему в некоторых случаях (например, наличие в запросе более одной группировки по многоуровневым справочникам с необходимостью получения для групп таких справочников развернутых в разрезе других группировок данных) делает такую "особенность" вполне достойной для описания в качестве именно "бага".
Автор: Cthulhu 18.08.12, 11:22
Баг DBF-SQL (запросы+бух.запросы).
При использовании в фильтре (отборе) списка значений результаты могут "вдруг" случиться разными.
Причина - некорректная обработка в SQL списков значений (в фильтрах запросов и бух.запросов), содержащих группы справочников.
Обход бага - если в SQL-версии в запросах и бух.запросах необходимо использовать фильтр по списку значений субконто типа "Справочник" - список значений должен содержать только элементы (не содержать групп).
прим.: в качестве срочного "костыля" при переходе с DBF на SQL можно использовать недокументированный метод объектов типа Запрос или Регистр - <Объект>.ВключитьSQL(0). Однако следует помнить, что этот метод очень сильно замедляет работу, и его рекомендуется использовать только в качестве "временного" решения проблемы.
Автор: XBrut 18.08.12, 12:54
щодо п.3.
...таке не стрічав, мабудь інтуітивно обходив.
Згоден з Cthulhu , якщо уважно придивитись - на "баг" жоден з трьох перших пунктів не тягне...
можливо доречно розділити тему на помилки & особливості
P.S.
Додаю до списку дуже бридку (і недокументовану) особливість : якщо маєте змінну модуля документу - ІНІЦІАЛІЗУЙТЕ ЇЇ ЯВНО. Інакше при пакетному проведенні неініціалізована змінна МОЖЕ бути не пустою, а зовсім навіть навпаки, може мати значення, що залишилось від проведення попереднього (!!) документу.
Типова ПУБ , наприклад цим нехтує.
Автор: mister-x 18.08.12, 13:04
тут і нюанси і особливості обговорюються, не всі знають 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 заходить аж до вибірки корсубконто і аж в тому розрізі пустота. Такі от помідори.
ЗІ. Оновив перший пост. Вдячний за пости.
Автор: Cthulhu 18.08.12, 15:08
Типова ПУБ , наприклад цим нехтує.
Именно так. Тело модуля выполняется при загрузке и компиляции формы документа / модуля документа. При групповом проведении (или даже при последовательном программном проведении документов одного вида) "движок" 1С "оптимизирует" этот этап - не перекомпилирует модуль, а использует тот, который уже был ранее скомпилирован и размещен в памяти. побочный эффект - в ранее скомпилированном и размещенном в памяти модуле "остаются в наследство" все переменные модуля со всеми "оставшимися" после предыдущего выполнения модуля значениями.
Встречается, увы, не только в ПУБ.
Автор: mister-x 18.08.12, 16:12
звідки такі відомості, можна лінк(и) чи Ви берете із досвіду об'єктно-орієнтованого програмування? цікаво про такі нюанси по 8.х дізнатися
Автор: Cthulhu 18.08.12, 16:28
инсайд. линков нет, что, впрочем, не странно в данном случае.
по 8.х - нет. пока просто неинтересно (а богатства багов, имеющего упоминания на просторах интернетов, не способствует появлению интереса).
Автор: mister-x 18.08.12, 16:47
зрозуміло, в більшості дізнаєтесь на форумах так як і я або в процесі практики
Автор: XBrut 19.08.12, 13:44
Якщо довідник має реквізит "Пиктограмма", то в формі списку довідника побачите цікавий результат.
Виявляється "Пиктограмма" - це також атрибут форми списку.
Платформа плутається, що саме показувати : реквізит , чи піктограму довідника
судячи з того, що в російських типових конфігураціях змінних модуля документів дуже мало, можна припустити, що існує рекомендація їх взагалі не використовувати.
від гріха подалі.
Автор: mister-x 19.08.12, 13:57
це системний атрибут, тому свої змінні потрібно називати інакше для уникнення плутанини
Автор: Cthulhu 19.08.12, 15:36
Использование ключевых слов встроенного языка в качестве названий объектов метаданных, реквизитов и переменных - крайне не рекомендуется. возникающие в результате несоблюдения данной рекомендвции баги вряд ли имеет смысл выделять каждый в отдельности. ну, мне так кажется.
А не-баги (полезные приемы и недокументированные особенности) - будем упоминать?..
Автор: XBrut 19.08.12, 16:21
Все так, але обставина, що зарезервований атрибут доступний для запису виглядає кумедно
ось ще якось надибав...
Якщо в регістрі є атрибут невизначеного типу, то в базі формату sql не працює конструкція в запиті
Условие(Атрибут В Список);доводиться робити так
Условие(Список.Принадлежит(Атрибут)=1);не працює також конструкція
Регистр.УстановитьЗначениеФильтра("Атрибут",Список,2);P.S.
окреме питання : якого дідька робити в регістрах атрибути невизначеного типу... але це вже інша історія.
Автор: mister-x 20.08.12, 11:50
в іншій темі
Автор: Vofka 20.08.12, 11:51
Ну вы б тогда либо дали ссылку на тему, либо сказали бы, что такой темы нету и в случае чего её нужно открыть
Автор: mister-x 20.08.12, 12:21
дозволяю відкрити
Автор: vadim007 27.08.12, 8:10
На выходных боролся с проблемой - не мог побороть.
Суть в следующем:
Внешний отчет, создает печатную форму. В модуле отчета описана процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Так вот, если диалог отчета не закрыт, то при клике на ячейке печатной формы вызывается описанная в отчете процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Если диалог закрыт, то вызывается описанная в глобальном модуле процедура ОбработкаЯчейкиТаблицы(..).
Для встроенных в конфигурацию отчетов вызывается описанная в модуле отчета процедура ОбработкаЯчейкиТаблицы(..), если она на самом деле имеется.
По моему, это баг платформы, побороть нельзя.
Автор: mister-x 27.08.12, 11:35
все ок
Если данная процедура описана в модуле формы, то вызывается она, иначе система запускает одноименную процедуру из глобального модуля.
Автор: alex040269 27.08.12, 12:20
Суть в следующем:
Внешний отчет, создает печатную форму. В модуле отчета описана процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Так вот, если диалог отчета не закрыт, то при клике на ячейке печатной формы вызывается описанная в отчете процедура ОбработкаЯчейкиТаблицы(Зн, Флаг, Конт, Ячейка).
Если диалог закрыт, то вызывается описанная в глобальном модуле процедура ОбработкаЯчейкиТаблицы(..).
Для встроенных в конфигурацию отчетов вызывается описанная в модуле отчета процедура ОбработкаЯчейкиТаблицы(..), если она на самом деле имеется.
По моему, это баг платформы, побороть нельзя.
как мне кажется - это не баг. Когда процедура существует (форма открыта) - вызывается из формы, когда не существует (форма закрыта) - вызывается из глобального модуля. Я когда-то с этим тоже парился... Пришел к выводу, что нужно закрывать таблицу при закрытии формы. Тогда выполнение программы выглядит более понятным для пользователя.
Автор: vadim007 27.08.12, 12:43
Если данная процедура описана в модуле формы, то вызывается она, иначе система запускает одноименную процедуру из глобального модуля.
Как раз вот это "Важно!" и не срабатывает в описанном мной случае.
Автор: alex040269 27.08.12, 13:00
Если форма закрыта, то 1с считает, что процедура не описана, т.к. ее нет в данный момент в памяти.
Автор: mister-x 27.08.12, 13:26
навіть якщо форма внутріншнього звіту чи обробки закрита, в цю форму відлагоджувачем (отладчиком) заходить в процедуру ОбработкаЯчейкиТаблицы?
Автор: vadim007 27.08.12, 13:46
Проверял отладчиком - не заходит, если формы нет на экране.
Автор: mister-x 27.08.12, 14:19
а в зовнішню обробку чи звіт, якщо він відкритий(а) також не заходить в цю процедуру?
Автор: vadim007 27.08.12, 15:40
Заходит. В том-то и прикол!
Автор: Ardi 27.08.12, 15:58
Почиталъ посты vadim007, переписавь хату на котя.
Автор: mister-x 27.08.12, 17:03
Автор: Cthulhu 27.08.12, 17:43
vadim007
Это не баг, скорее недокументированная особенность. При открытии формы выполняется её компиляция и размещение в памяти, после чего выполняется тело модуля. Пока форма открыта (размещена в памяти) - из элементов её диалога доступны процедуры и функции модуля - это вопросов и стремлений что-то "побороть" не вызывает, верно?.. так вот, для "дочерних окон" - в частности, для окон с выведенными в них таблицами - механизм полностью аналогичен. Или более аккуратно сформулировать если, то вот:
Для таблиц, сформированных (и показанных) из модуля открытого экземпляра формы (любой!), предопределенные процедуры (в частности ОбработкаЯчейкиТаблицы) выполняется в контексте открытого экземпляра формы (из модуля этой формы) пока этот экземпляр формы открыт; иначе выполняются предопределенные процедуры (в частности ОбработкаЯчейкиТаблицы) Глобального Модуля.
И - извиниТЕ, но и для "встроенных" (включенных в метаданные) отчетов и обработок - это правило точно так же действует, т.е. если форму, из которой сформирована таблица, закрыть - предопределенная процедура ОбработкаЯчейкиТаблицы будет вызываться из глобального модуля (который компилируется и размещается в памяти во время загрузки конфигурации и "живет вечно" в рамках сеанса работы). так что это Вы, похоже, ошиблись просто.
Автор: vadim007 28.08.12, 7:12
Можно ссылку на первоисточник?
Автор: alex040269 28.08.12, 7:25
процедура описана до тех пор, пока открыта форма.
Автор: vadim007 28.08.12, 8:18
Мне нужна одинаковая реакция на клик в ячейках таблицы, независимо от того, висит форма отчета в памяти или нет.
Придется дописывать в глобальном модуле.
Автор: Cthulhu 28.08.12, 9:27
Придется дописывать в глобальном модуле.
ещё вариант - таблица в режиме ввода данных.
только не ОбработкаЯчейкиТаблицы, а ПриВыбореЯчейки.
Автор: alex040269 28.08.12, 12:14
саме на зовнішніх я і тестував. в мене була потреба робити звіти без зміни та під різні конфігураціі. Поки форма відкрита викликається процедура з форми. Все логічно.
Автор: Ardi 28.08.12, 13:28
Я так думаю печатную форму нужно выводить в ФОРМУ ОБРАБОТКИ а не отдельно. И всё получится.
Автор: mister-x 28.08.12, 14:53
Придется дописывать в глобальном модуле.
в такому випадку - прийдеться
Автор: Cthulhu 25.09.12, 14:33
ещё один довольно редко встречающийся, но очень неприятный баг.
при добавлении в подчиненный справочник с установленным отбором (с редактированием "в списке") эпизодически происходит дублирование внутреннего Id (того самого, по которому движок определяет "именно этот объект данных").
Автор: vadim007 26.09.12, 10:16
Еще одна особенность при обновлении измененных конфигураций. Давно сталкивался, и вот снова те же грабли:
Редактируем конфигурацию заказчика у себя. В неком документе имя реквизита ВидОплаты меняем на ФормаОплаты (так кажется более логично, т.к. он типа Перечисление.ФормаОплаты). Сохраняем конфу, приезжаем к заказчику, обновляем конфу. В окне "Объединение конфигураций" 1С честно предупреждает: ФормаОплаты: Объект добавлен; ВидОплаты: Объект удален, Возможна потеря данных!!!
Проверяем, правда-ли это - принимаем изменения, запускаем 1С, открываем документ - так и есть: реквизит ФормаОплаты у заказчика пуст!
Т.о., обновление в таких случаях нужно делать за два шага: непосредственно у заказчика изменяем имена реквизитов, если такое требуется, а затем обновляем конфу.
Автор: alex040269 26.09.12, 10:24
Редактируем конфигурацию заказчика у себя. В неком документе имя реквизита ВидОплаты меняем на ФормаОплаты (так кажется более логично, т.к. он типа Перечисление.ФормаОплаты). Сохраняем конфу, приезжаем к заказчику, обновляем конфу. В окне "Объединение конфигураций" 1С честно предупреждает: ФормаОплаты: Объект добавлен; ВидОплаты: Объект удален, Возможна потеря данных!!!
Проверяем, правда-ли это - принимаем изменения, запускаем 1С, открываем документ - так и есть: реквизит ФормаОплаты у заказчика пуст!
Т.о., обновление в таких случаях нужно делать за два шага: непосредственно у заказчика изменяем имена реквизитов, если такое требуется, а затем обновляем конфу.
Это не баг, а правда жизни, т.к. 77, в отличие от 8, сравнивает объекты только по идентификатору, а не по внутренней ссылке
НО если переименовать в основной базу УРБД, то в периферийной тоже переименуется.
Автор: Cthulhu 26.09.12, 14:40
77 в отличие от 8 сравнивает и по идентификаторам, и по внутренним Id - зависит от желания программиста (если программист недостаточно профессионален - от воли случая).
УРБД, получая в согставе очередного обмена изменения конфигурации (в виде упакованного 1cv7.md в составе файла автообмена) - выполняет именно "загрузку измененной конфигурации".
Автор: sava1 26.09.12, 15:02
Поддерживаю
Автор: Cthulhu 26.09.12, 15:39
Автор: Vofka 26.09.12, 15:48
Уважаемые писатели данного топика!
Вам удобно все это писать и обсуждать в одной теме? Может создать подраздел где-то какой-то, или можно каждый полезный прием постить, например, http://pro1c.org.ua/index.php?showforum=74 в отдельной теме. А то получается каша. И чем больше в этой теме постов - тем больше вся полезная информация этой темы превращается в кашу.
Можно отвечать прям тут, а после обсуждения, если оно будет, мы решим что делать и мусор уберем.
Автор: Cthulhu 26.09.12, 15:52
Vofka
Тогда уж http://pro1c.org.ua/index.php?showtopic=8021 http://pro1c.org.ua/index.php?showtopic=8955.
Автор: Cthulhu 19.11.12, 12:33
Оживлю.
Общий реквизит документов типа "строка" неограниченной длины. Будучи НЕ последним в списке общих реквизитов (в дереве метаданных). В SQL-версии ведет к вылетам по внутренним SQL-ошибкам.
Отсюда - полезное универсальное правило:
На всякий случай. Всегда и везде. Общие реквизиты документов типа "строка" неограниченной длины в списке общих реквизитов дерева метаданных - смещать в самый низ списка.
Автор: mister-x 19.11.12, 12:52
цей баг виявлено на sql 2000 SP4 чи і пізніших версіях?
Автор: Fynjy 19.11.12, 12:59
На всех.
Автор: mister-x 17.12.12, 21:38
маємо:
ит.ИспользоватьСубконто(ВидыСубконто.Контрагенты,СписокСубконто,1,0);
ит.ВыполнитьЗапрос(НачалоПериода,КонецПериода,"361", , ,1,"День","С");
Ит.ВыбратьСубконто();
Пока ит.ПолучитьСубконто() = 1 Цикл
ит.выбратьПериоды();
пока ит.получитьПериод()=1 цикл
...С-П:
Синтаксис:
ВыбратьПериоды(<ФлагВсе>,<ФлагДК>,<Номер>,<РазвСальдо>)
Назначение:
Открывает выборку периодов.
Возвращает 1 - если действие выполнено и в выборке есть хотя бы один период; 0 - если действие не выполнено или в выборке нет ни одного периода.
Параметры:
<ФлагВсе> - число: 0 - отбирать те счета, которые имели итоги на этом уровне обхода итогов запроса; 1 - включить в выборку все счета, которые имели итоги в данном запросе; -1, -2 : включить в выборку счета, которые имели итоги в группировке n-го вышестоящего уровня. По умолчанию - 0.
<ФлагДК> - число: 1 - включать в выборку счета только с дебетовыми оборотами; 2 - включать в выборку счета только с кредито-выми оборотами. 0 - включать в выборку счета вне зависимости от дебетовых/кредитовых оборотов. По умолчанию 0.
<Номер> - число - номер выборки. Если параметр не указан, выборке присваивается номер 0.
<РазвСальдо> - признак необходимости рассчитывать развернутое сальдо по субконто. Используется только если в запросе участвуют субконто. 1 - рассчитывать развернутое сальдо. 0 - не рассчитыть развернутое сальдо; По умолчанию 0.
Що маємо реально, якщо по даному контрагенту за вибраний період не було оборотів, то в цикл по періодах не заходить - тобто напр., початкове сальдо по дт = 30 = кін. сальдо по дт=30.
Якщо ж
ит.выбратьПериоды(1);в цикл по періодах заходить, навіть, якщо маємо ситуацію із прикладу.
Тобто, або під цим
взагалі не правильно описано. Або я щось не так зрозумів із опису даного методу.
Хтось з таким зустрічався?
ЗІ. СписокСубконто - список на формі, в списку може бути і група.
Автор: XBrut 04.06.14, 9:58
Знову про ОбработкаЯчейкиТаблицы()
Реліз платформи 27
1) робимо зовнішній звіт.
2) готуємо локальний виклик ОбработкаЯчейкиТаблицы() все як положено, щоб він працював.
3) а тепер переносимо створення Таб=СоздатьОбъект("Таблица") в модуль форми (вниз , щоб объект створювався під час компіляції)
...все. виклику ОбработкаЯчейкиТаблицы() нема іде глобальний виклик.
П.С.
прошу товарішів перевірити.
Автор: Sanyk 06.06.14, 12:06
Є таке. Зустрічався. Від місця, де розташована процедура "ОбработкаЯчейкиТаблицы()" в тексті, залежить, яка сама процедура буде викликатись (глобальна чи локальна).
Автор: XBrut 07.06.14, 14:41
Я мав на увазі місце створення об'єкту "Таблиця", а не місце процедури ОбработкаЯчейкиТаблицы(). Поясніть , що саме бачили ви.
Автор: Sanyk 10.06.14, 17:01
Мабуть в минулий раз я Вас не правильно зрозумів. В моїй практиці були ситуації щодо виклика локальної процедури "ОбработкаЯчейкиТаблицы". Якщо в тексті модуля локальна процедура знаходилась нижче від місця вмклику (виклик процедури не завжди виконується з таблиці), то викликалася глобальна процедура.
Взагалі я намагаюсь не описувати змінні внизу модуля форми, аби не мати проблем. (100 % проблеми гарантовані в модулі проведення документів при групових обробках, при чому є проблеми з змінними які описані знизу в глобальному модулі (наприклад, для ПУБ це таблиця глТбОперация, не завжди для нового документу видаляються старі записи))
Автор: XBrut 10.06.14, 18:05
логічна, але неочевидна поведінка прогами. Автор: alex040269 11.06.14, 7:34
//*******************************************
Процедура ПриОткрытии()
КонецПроцедуры
Таблица = СоздатьОбъект("Таблица");
Таблица.ИсходнаяТаблица("Таблица");результат:
{D:\1С\7\ZP\EXTFORMS\1.ERT(7)}: Неверное имя Таблица
//*******************************************
Процедура ПриОткрытии()
Таблица = СоздатьОбъект("Таблица");
Таблица.ИсходнаяТаблица("Таблица");
Сообщить("1");
КонецПроцедурырезультат:
Автор: mister-x 11.06.14, 9:38
Таблица випадково не реквізит форми?
Автор: alex040269 11.06.14, 9:59
Таблица - Таблиця, яка існує в формі оброьки/звіту після створення!
Автор: mister-x 11.06.14, 11:20
В СП:
Синтаксис:
Таблица
Назначение:
Атрибут (только для чтения) представляет собой ссылку на объект типа ''Таблица''. Доступ к данному атрибуту возможен только в контексте Модуля формы отчета или обработки. При настройке формы отчета (обработки), если табличный документ размещен непосредственно в форме (для этого в диалоге, вызываемом пунктом ''Свойства формы'' меню ''Действия'' в параметре ''Использовать таблицу'' выбирается вариант ''Пустую'' или ''Для ввода данных''), то доступ к такому объекту осуществляется через атрибут контекста формы отчета (обработки) Таблица.
Атрибуты и методы объекта ''Таблица'' позволяют в программном модуле управлять процессом формирования и визуального отображения таблицы в целом, а также изменять свойства визуального отображения отдельных областей таблицы.
В тексте программного модуля через точку после имени атрибута ''Таблица'' можно записывать адреса областей таблицы, а далее через точку можно вызывать методы управления свойствами этих областей.
отже, це слово в обробці чи в звіті зарезервоване - приклад використання в обробці "Информац. блок"
Автор: mister-x 15.11.15, 23:32
Надибав цікаву статйку - http://pro1c.org.ua/redirect.php?http://infostart.ru/public/83887/, пригодиться.
Автор: DartRomanius 16.11.15, 2:21
Так, и ще коментарі читати обов'язково.....
Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7
https://pro1c.org.ua