Некоторые ошибки 1С:Предприятия 7.7 различных релизов.

Глюк при использовании сортировки в таблице значений.

Вообщем мне понадобилось отсортировать ТаблицуЗначений по колонке, а потом найти значение. Метод НайтиЗначение() начал работать криво. Стало интересно...исследовал. Написал простенький примерчик:

Процедура Сформировать()
ТЗ =СоздатьОбЪект("ТаблицаЗначений");
ТЗ.НоваяКолонка ("Колонка","Число" );
ТЗ.НоваяСтрока (); ТЗ .Колонка =0;
ТЗ.НоваяСтрока (); ТЗ .Колонка =0;
ТЗ.НоваяСтрока (); ТЗ .Колонка =1;
ТЗ.Сортировать ("Колонка");
Сообщить(ТЗ .НайтиЗначение(1 ,1,"Колонка" ));
КонецПроцедуры
... если ТЗ.Сортировать ("Колонка") закомментировать, то все нормально. При использовании метода Сортировать( ) метод НайтиЗначение (Знач ,Строка,Колонка ) игнорирует параметр "Строка" и соответственно ищет не в заданной строке, а по всем строкам. Причем позиционирование после сортировки на первую строку ТЗ ничего не дает...

В данном случае были установлены параметры поиска в первой строке и первой колонке. До исполнения метода Сортировать() все отлично работает и метод ТЗ .НайтиЗначение(1 ,1,"Колонка" ) возвращает 0 (т.е. значение не найдено). После же сортировки тот же метод возвращает 1. Явно прослеживается глюк исполнения какого-то из вышеупомянутых методов.

Причина такого поведения метода НайтиЗначение(), по моему мнению, связано с неправильным индексированием таблицы значений после исполнения метода Сортировать(). Хотя до конца не понятно, что же все-таки глючит, метод НайтиЗначение() или метод Сортировать() ? В любом случае, все вышесказанное указывает на ошибки работы с массивами.

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

ТЗ_2=СоздатьОбЪект("ТаблицаЗначений");
ТЗ.Выгрузить( ТЗ_2);
Сообщить(ТЗ_2 .НайтиЗначение(1 ,1,"Колонка" ));

Глюк исполнения метода обЪекта XBase.

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

В данной версии статьи я не буду приводить пример, иллюстрирующий неправильную работу этого метода, а ограничусь лишь описанием случая при котором проявляется эта ошибка.

Впервые эта ошибка возникла в 15-м релизе (заметьте, в 14-ти предыдущих все было нормально). Фирма "1С" в очередной раз исправила одни ошибки, а наплодила еще больше других. Так как обЪект XBase не позволяет использовать мемо-поля, то иногда требуется использование строковых полей довольно большой длины. В такие поля, например удобно упаковывать агрегатные обЪекты с помощью метода ЗначениеВСтрокуВнутр(КакойТоОбЪект). Теперь собственно к главному, метод НайтиПоКлючу(<Режим>) всегда возвращает 0, если длина поля превышает 200 символов. В итоге мы получаем дополнительный приступ гемороя при разбитии таких полей на не превышающие 200.

Глюк при конфигурировании списка и прав пользователей.

Глюк обнаружил Петр и опубликовал в коференции на Кубани "Территория 1С". Здесь можно посмотреть текст ветки. Вот цитата из текста письма, который он мне прислал. 

"Метод обломный и слегка позорный - я сообразил, что такое возможно, сам налетел на баг.
По шагам.

1 - заводишь набор прав с полными правами ППП.
2 - создаешь пользователя ХХХ с этими правами ППП.
3 - сохраняешь конфигурацию и пользователей.
4 - копируешь полученный User.usr в другое место - это будет ПРОПУСК в дальнейшем
5 - Заходишь в конфигуратор.
6 - Удаляешь пользователя ХХХ.
7 - Сохраняешь Список Юзеров, закрываешь его
8 - А теперь - баг. Если зайти в права и удалить у всех право администрирования, (кроме ППП, естественно), то конфа СОХРАНИТСЯ ! ! !

Если попытаться просто удалить последнего юзера с правом администрирования, система заорет и не пропустит, а так - запросто. То есть юзера с администрированием просто не останется.

Тогда и зайти с правами администрирования нельзя. Никуда не пустит. Как оказалось, снимается с использованием всем известного метода - убрать User.usr при запуске, затем подложить назад и отредактировать. Там права доступа - по барабану..."

Форма. Баг метода Видимость.

Прислал Моисеенко П.П.

(c) - взято с Бурги. Автор разыскивается. Хотя я и знаю про данный глюк, я его не публиковал. Глюк проявляется в том, что при запуске формы поле не видно, только если установить видимость=0 и доступность=0 ОДНОВРЕМЕННО (по крайней мере на 12, 15 и 17 релизах). Совет с Бурги - Необходимо устанавливать флаг Доступность(0) а потом Видимость (0), если их переставить реквизит будет виден.

Форма. Фича многострочной части документа.

Прислал Моисеенко П.П.

Заключается в том, что видимостью многострочной части документа можно на самом деле управлять (я проверял на 10, 14,15,17 релизах). Делается это так -
Форма. МногоСтрочнаяЧасть. Видимость( Режим)
Режим: 1 - показать табличную часть, 0 - скрыть табличную часть документа
Возвращаемое значение - Число - 1 - табличная часть видима, 0 - нет.

План счетов, субконто. Разрешение редактирования операции

Прислал Моисеенко П.П.

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

План счетов, субконто. Программное создание и удаление субконто

Прислал Моисеенко П.П.

(c) - взято с Бурги. Автор разыскивается.

Оказывается, в 1С, программно, конструкцией следующего вида
Сч = СоздатьОбЪект ( "Счет" );
Сч.НайтиСчет ( <какой-нить счет> );
Сч.ВидСубконто (<номер субконто> , <новый вид субконто> );
Сч.Записать ();

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

Замечание - при попытке изменить аналитику на счете, заданном в конфигураторе, нас посетит Обломов - выдается сообщение "Изменение настроек счета, введенного в режиме конфигуратора, запрещено!". Ну хоть это нормально. По крайней мере, у меня на локальном 15 и 17 релизах так.

В итоге имеем: юзер ввел при создании счета одно субконто, а реально имеем совершенно другое после программного изменения! При этом все прекрасно и никаких конфликтов. Аналитика ушла в пампасы. Ну по документам после восстановления субконто можно восстановить аналитику перепроведением, а с ручными операциями как? После изменения субконто потребуется полный пересчет итогов, и вся аналитика в ручных операциях исчезнет.
Комментарий: -Сам проверял. Как с куста работает.
Сам факт возможности изменения субконто описан в документации 1С, только явно не сказано, что можно менять только в счетах, созданных не в конфигураторе. Там можно менять практически все свойства счета.

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

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

Изменение проводок документа без перепроведения

Прислал Моисеенко П.П.

И(c) - взято с Бурги. Автор разыскивается. Было только 1 раз.
Мною данная фича (баг) не проверялась!
Оп = СоздатьОбЪект("Операция");
Док = СоздатьОбЪект("Документ" );
Док.НайтиДокумент ( НужныйДок );
Оп. НайтиОперацию ( Док.ТекущийДокумент ());
Оп. ВыбратьПроводки ();
Пока Оп. ПолучитьПроводку() = 1 Цикл
          //Здесь можно поменять реквизиты проводки, например, Первое Субконто кредита
          Оп .Кредит .Субконто (1,СубКон );
КонецЦикла;
Оп. Записать();
Ответ автора данного метода - Меня такой метод настораживает, но один раз действительно было очень надо и пока никаких последствий не вылезло. Экспериментально не проверялось.

Ошибка при добавлении проводки

(c) - Белов Сергей aka Soaron
Имеем конструкцию типа в модуле проведения документа:
Операция .НоваяПроводка ();
...
Операция .НоваяПроводка ();
...
Операция .НоваяПроводка ();
...
Операцию и проводки не сохраняем. Пока. Теперь мы хотим прочитать, допустим, первую созданную нами проводку:
Операция.ВыбратьПроводки ();
Операция. ПолучитьПроводку();
Теперь мы хотим добавить еще одну проводку, обычным способом:
Операция .НоваяПроводка ();
...
Однако ни ....я. она не будет добавлена, она будет проводкой номер два с дробью. Вообще, если разобраться, метод НоваяПроводка() должен добавлять пустой элемент в конец списка. Этот пример показывает, что это не так, получается, что при такой конструкции этот метод вклинивает проводку между двумя другими. Очевидно, внутренний дескриптор текущей проводки также является еще показателем количества проводок. При этом, если проверить базу Тестированием и Исправлением, то 1с ругнется на эти проводки и удалит дробные нахрен, у нее это называется "преобразование сложной проводки в простую". Если посмотреть описание метода НоваяПроводка(), то оно будет таким: "...Метод создает новую проводку для текущей операции. Новая проводка становится текущей....", нигде ни слова про сложную проводку, сложная появляется только после использования метода НоваяКорреспонденция() , который я вообще никогда не использовал. За эту ошибку я бы всех программеров из 1с уволил.
Исправляется следующей конструкцией:
Операция .ВыбратьПроводки ();
Операция. ПолучитьПроводку();
...
...
Пока Операция. ПолучитьПроводку()=1 Цикл
КонецЦикла;
Операция. НоваяПроводка();
...
То есть мы должны пройти по ВСЕМ существующим проводкам, и уж потом создавать новую.

Последовательность представления субконто

Прислал Моисеенко П.П.

(c) - взято с Бурги. Автор разыскивается. Было только 1 раз
Вылазит в форме списка, при редактировании счета в диалоге или программном изменении реквизитов счета - все нормально. 1С 7.7(15). SQL и DBF валится одинаково, только SQL стоит под W2000 и слетает "молча", DBF стоит под NT и вываливает ошибку "Memory could not be "read"./ Ответ автора данного бага - Сам себе отвечаю, может, кому пригодится: убрать в форме списка колонку "Субконто4", либо поставить подряд "Субконто1", "Субконто2", "Субконто3" и "Субконто4" (а были не подряд).

SQL.Не работает условие в запросе

(c) http://1csql.udmnet.ru - toypaul
При переходе с dbf в SQL запрос не хочет выбирать Контрагента,Товар по условию. Текст запроса: - см http://1csql.udmnet.ru В запросе используется измерение Сотрудник --- Измерение неопределенного типа
Релиз 17 , ОДБС 3.510.3711
Выдает пустой запрос. В dbf все работает.
Вся проблема в измерении неопределенного типа. Если поставить условие по этому измерению - всегда выдает 0, в dbf работает.  Возможные решения: Вплоть до 14 или 15 релиза подобные запросы вызывали "вылет" предприятия. На 14(15) работало. -- Замена релиза это не интересно, пришлось в обходах группировки проверять.

SQL.Группа справочника в запросе

(c) http://1csql.udmnet.ru - toypaul
Под SQL 1С не подгребает данные в отчет, если указана для отбора группа справочника. База dbf - все нормально (отбор по группе работает). На ИТС пишут: "...Однако, не следует группы справочников в качестве значений субконто". Все это понятно, но тогда почему dbf работает.
Возможные решения:
Т.е. ты пишешь Ит.ИспользоватьСубконто(ВидСубконто, Группа, 2)
Попробуй Ит.ИспользоватьСубконто(ВидСубконто, Группа, 1) это работает без проблем, выборку можно и не обходить, а время запроса практически не увеличивается

SQL.Ошибки при формировании SQL запроса в 1С

(c) http://1csql.udmnet.ru - toypaul
Проблема: при переходе с dbf на sql в некоторых отчетах (конф. Производство) sql начинает выдавать error типа
Line2:Incorrect syntax near 'ra3887' и т.д и т.п
Возможные решения:
Ошибка означает, что SQL-запрос, сформированный 1С составлен неверно (Incorrect syntax). Решение может заключаться либо в написании текста запроса так, чтобы 1С смогла сформировать верный SQL-запрос, либо в смене релиза (в этом случае, если запрос будет работать, обязательно проверьте работу других запросов). А еще неплохо было бы послать текст запроса на hotline 1С (вместе с конфигурацией), чтобы баг был исправлен в следующем релизе.

SQL.Метод РассчитатьИтоги

(c) http://1csql.udmnet.ru - toypaul
Перешли на SQL. Теперь в доке "Выписка банка" при нажатии кнопки "Показать остатки" выдается какое-то левьё. Если смотреть стандартные отчеты, то по счетам все нормально, все остатки выдаются правильно. Косяк только в этом документе. Если сделать выгрузку, а потом загрузить под ДБФ, все работает нормально. Как с такой хренью бороться? Релиз предприятия 15, конфы 301(это Комплексная) Возможные решения:
Это старая песня. В 7.7 под SQL не работает метод РассчитатьИтоги(,,) Надобно через запрос энто дело переписывать. Это было обнаружено на первых же релизах 7.7. Ее правят-правят и никак не поправят. Вроде, если период месяц или день то уже правильно работает. За 10 релизов подправили... К сотому обещали исправить остальное.

Дыра в защите - формульный калькулятор

Прислал Моисеенко П.П.

Дыра номер 1 - если пользователю запретить использовать внешние и общие отчеты и обработки (см. настройку Прав), то тем не менее можно запустить внешний отчет и обработку. Для этого необходимо выполнить следующие действия:
1. открыть окно формульного калькулятора (Меню --> Табло)
2. набрать в этом окне вызов функции
ОткрытьФорму ("Отчет" , , "Диск:\каталог\имя_файла_отчета.ert")
и данный отчет/обработка будут загружены и запущены на выполнение. Диск и каталог можно не указывать - по умолчанию будет использован либо каталог базы, либо каталог пользователя (что конкретно, не помню, но это и не важно). Как видно из приведенного, рядовой юзер не шибко грамотен и вряд ли сам сообразит, что нужно написать. Но не нужно рассчитывать на неграмотность юзера. К сожалению, он иногда (редко, правда) умеет учиться. Запрет использования любых и общих внешних отчетов запрещает вызывать их только через Меню --> Файл --> Открыть. Для Табло это не работает. Для убирания этой дыры необходимо в правах (в настройке Прав) снять еще одну галку - Использование функций в табло и формульном калькуляторе. Таким образом, будет запрещено использование функций в табло и выполнить функцию ОткрытьФорму (...) не удастся. Недостаток данного способа убирания бага состоит в том, что если юзер активно юзает табло (что, кстати, на моем опыте - встречалось пару раз, не более), ему будет перекрыто горлышко.

Внедрение вставок во внешние отчеты и обработки

Прислал Моисеенко П.П.

Дыра номер 2 - если пользователю запретить использовать внешние и общие отчеты и обработки (см. настройку Прав), то грамотный юзер (знакомый с программированием), тем не менее, может запустить внешний отчет и обработку. Для этого можно воспользоваться хранящимися в каталоге ExtForm стандартными отчетами. Нужно просто немного подредактировать любой стандартный отчет. Например, найти процедуру ПриОткрытии и в ней поставить ОткрытьФорму. Так как проверки прав в программном режиме нет, то данный оператор будет выполнен и открытие одной формы откроет и еще одну или несколько. Как закрыть дыру? Для локальных вариантов 1С , если база на локальном диске - никак. Для сетевых вариантов и локальных, при расположении базы на сетевом диске - закрыть дыру можно администрированием прав пользователя на сервере. Для пользователя должно быть установлена защита ТОЛЬКО ЧТЕНИЕ. Тогда он не сможет изменить файлы стандартных отчетов на диске сервера.

Внедрение вставок в модули документов

Прислал Моисеенко П.П.

Дыра номер 3 - аналогична дыре номер 2, однако чуть иная. Как известно, существует оператор ЗагрузитьИзФайла. Довольно часто он применяется при эксплуатации системы при достаточно большом числе пользователей. Это позволяет программисту отлаживать логику загружаемого модуля прямо на ходу, не прерывая работы пользователей. Иногда такая практика существует постоянно. И модули доков болтаются в каталоге базы постоянно. Сам так работал - это достаточно удобно при частых изменениях, наблюдается всего лишь небольшая задержка при открытии документа. Способ внедрения закладки в модули такой же, как и в отчеты. Например, найти процедуру ПриОткрытии и в ней поставить ОткрытьФорму. Так как проверки прав в программном режиме нет, то данный оператор будет выполнен и открытие дока на просмотр откроет требуемые отчеты и обработки. Как закрыть дыру? Для локальных вариантов 1С , если база на локальном диске - никак. Для сетевых вариантов и локальных, при расположении базы на сетевом диске - закрыть дыру можно администрированием прав пользователя на сервере. Для пользователя должно быть установлена защита ТОЛЬКО ЧТЕНИЕ на файлы, в которых находятся модули доков. Тогда он не сможет изменить эти файлы на диске сервера.