my 1C. Полезная информация.

Попытка обобщить имеющуюся информацию о релизах платформы 1С-Предприятие:
4
Насколько я помню, это был первый релиз, на котором я начал работать с 7.7. Причиной перехода на более поздние релизы стала неверная обработка субконто после бух.запроса (вылезло при Начислении амортизации, приходилось переписывать код).

12
Наверное, первый из серии безглючных, я сам на нем работал до перехода на 15. Хотя причиной перехода был именно какой-то глюк :)

15
один из наиболее стабильных. Явных глюков не припоминаю. Причиной перехода на более поздние релизы стало сообщение, что они, якобы, работают быстрее.

18
В данном релизе исправлена ошибка возникающая при работе 1С:Предприятия для SQL с MS SQL Server. Ошибка связана с тем, что у ODBC драйверов входящих в состав MDAC 2.6 и выше (версия драйвера SQL Server 2000.80.194.0 и выше) изменено поведение при чтении полей неопределенной длины. Ошибка проявлялась при работе со строковыми реквизитами неограниченной длины, если их в структуре объекта присутствует более одного. Партнерам Фирмы 1С рекомендуется установить новый релиз у пользователей версии 1С:Предприятия для SQL.
В данном релизе изменено поведение метода документа "Провести" при вызове его для переменной созданной функцией "СоздатьОбъект". Если документ был изменен перед вызовом метода и не записан, то при вызове проведения автоматически выполняется запись документа.
В данном релизе исправлена ошибка приводящая в некоторых случаях к неверному вычислению развернутого сальдо в объекта "БухгалтерскиеИтоги". Это может привести к изменению поведения некоторых существующих отчетов.
<Сообщил Руководитель отделения разработки экономических программ Сергей Нуралиев>

Недавно я столкнулся с одним глюком в 18 релизе, DBF сетевая, на SQL не проверял. Суть заключается в неправильном получении информации по регистрам остатков в запросах, если учитываются не все измерения регистра.
Опишу последовательность действий для воспроизведения:
1) В демо базе Комплексной 4.32, 4.42 (думаю, можно взять и ТиС или любую конфу на оперативном учете, важно наличие документов, двигающих регистры) вводим документ "Ввод остатков - долг поставщика фирме", проводим, получаем движение регистра "Взаиморасчеты поставщиков".
2) В следующем месяце (отчеты строились помесячно) вводим "Строка выписки банка - приход" с видом оплаты "Возврат от поставщика", на ту же сумму задолженности, проводим.
3) Сравниваем движения регистра "Взаиморасчеты поставщиков" - они отличаются только измерением "Кредитовый документ" - выписка подставляет себя вместо документа ввода остатков - возможно, это ошибка конфигурации, т.к. регистр не выводится в ноль, но нам данная ситуация показывает глюк платформы.
4) Выводим отчет "Ведомость по контрагентам", или можно воспользоваться универсальным отчетом по регистрам с ИТС. Ставим фильтр по Контрагенту, Договору, Фирме. Выбираем группировки Договор, Вид долга (по минимуму можно обойтись фильтром по Контрагенту и группировкой по Договору). Выбираем период отчета равный месяцу выписки банка - в отчете все ОК, на конец периода долга нет.
5) Теперь выбираем период, следующий за выпиской (например долг вводили 31.12.2002, выписку - 10.02.2003, отчет строим за март). Получаем нач. долг (остаток) = кредитовому обороту за пред. период (сумма выписки). Также и в последующих периодах, если не было движений по данному контрагенту, на начало выводится та же сумма, причем остаток на конец = 0.
Поставил 17 релиз - все ОК, отчеты выводятся правильно. Не знаю, будет ли воспроизводится данная ошибка в других
ситуациях - если документы ввода долга и выписку вводить в одном месяце например ...
<Сообщил Олег Морозов>

Данная программа наглядно демонстрирует одну (из огромного количества) из ошибок 18-го релиза в оперативном учете.
Многие программисты до сих пор считают, что 18-тый релиз абсолютно корректно работает с опер. учетом. Реально это не так, причем итоги ползут очень здорово. Данная программа должна помочь, во избежание неприятностей, принять им решение о переходе на другие релизы оболочки
<Сообщил NS>

19
Для компоненты "Оперативный учет" SQL версии 19 релиз на сегодняшний день лучший! Около года работал на 15 релизе (в общей сложности ~80 пользователей), пробовал работать на 17, 18 релизах (отказался сразу: ошибки в запросах). Уже больше месяца использую 19 релиз - многие запросы стали выполнятся на порядок (т.е. более чем в 10 раз) быстрее. Это легко заметить визуально (правда у меня самописная конфа и период хранения итогов 5 дней). Если раньше для того, чтобы вычислить функции "Приход", "Расход" 1С сканировала таблицу движений регистра, то теперь она использует для этого таблицу итогов (как и было задумано). Кроме того, в сравнении с 15 релизом стало работать корректно (и быстро!!!) условие "В" по группе, списку значений. И т.д. и т.п. Еще много приятных мелочей. Крупных глюков не встречал. Мои рекомендации - ставь 19 релиз если используешь SQL сервер и компоненту "Оперативный учет".
<сообщил mick>
Замечание к вышеизложенному от Павла Шемякина: Как могут рассчитываться эти функции, если в таблице итогов (если мы говорим про регистры остатков) таких полей нет? Если речь идет о оборотных регитрах, то так и нужно написать, но там просто нет таких функций - только функция Сумма, которая по-моему всегда так и работала. Так что получается - данная строчка не соответствует действительности.

Поставил 19-ый, через 5 минут вернулся на 15-ый :(((
Остался глюк (как и в 18-ом) в запросе к периодическим реквизитам справочников (SQL-версия). В ДБФ все нормально.
15-ый релиз SQL работает корректно, но, действительно, медленнее чем 19-ый.
<сообщил AlexNik>

Слышал, что в 19 сделали какую-то модную защиту, так коряво, что она в терминалах отказывается находить ключ защиты... При таком косяке рекомендуют оставаться на 18-ом.
<сообщил Mark II>

Под терминалом не хочет работать вместе с Соболем, а лицензия работатет без проблем (у меня работает). Хорошего тоже есть немножко, под SQL некоторые запросы стали выполняться быстрее, убрали некоторые глюки (по регистрам и ЖурналуРасчетов), но появились по Бухгалтерии:
1. Если делать запрос по операциям обыкновенным запросом (не бухгалтерским) с группировкой по документам (операциям, проводкам), то в этой группировке не будет ни одного элемента.
2. Глюк касается SQL. При временном расчете бух.итогов и получении Сальдо по счету-"группе", где нет субконто, а у субсчетов есть субконто - сальдо берется без учета значений субконто.В dbf все правильно.
<сообщил p_vaseI>

(... повторяй действия В ТОЧНОСТИ ...)
Возьми 19 релиз.
Возьми типовую рос. бухгалтерию 4.3х (или 4.2х). Открой _монопольно_ (дбф) демо-базу.
Найди выписку за 11.01.02. Найди там строку 2 по Швейной фабрике.
Удали в ней кор.счет. Проведи выписку, посмотри проводки.
(получим проводку 60.1 - 51.1)
Закрой все окна. Зайди в "операции - проведение документов".
Выбери вид документов - Выписки (можно и все), дата _с_ "11.01.02", по - неважно.
Жми кн. "Провести".
Посмотри проводки. Найди разницу с ручным проведением.
(здесь получим проводку 60.2 - 51.1. Т.е получаются разные проводки в зависимости от метода проведения)
Повтори процедуру с "Операции - проведение документов" на 20 релизе и убедись, что проводки совпадают с ручным проведением.
<сообщил Шурик71>

20 (вышел 28.11.2002)
Тестирование производилось на конфигурации, в которой собраны моменты, приводящие к "вылету" программы.
Итак:
1. Ошибка возникает при попытке войти в группировку, не описанную в запросе. Если стоит признак "С расшифровкой", то вторая группировка создается, и обход запроса выполняется, если галки нет - ОШИБКА! (Для проверки требуется "Оперативный учет") - ИСПРАВЛЕНА
2.
перем ВыбЗнач;
сзВыбор = СоздатьОбъект("СписокЗначений");
сзВыбор.ДобавитьЗначение("");
если сзВыбор.ВыбратьЗначение(ВыбЗнач,"",,,2) = 0 тогда
Сообщить("!!!");
конецЕсли;
НЕ ИСПРАВЛЕНА
3.
При попытке обращения в процедуре "ПриОткрытии" модуле формы документа к реквизиту, вставленному как текст. - НЕ ИСПРАВЛЕНА
4.
Формат(0,"Ч(0)10.2")=0000000.00
Формат(0,"Ч(0)10.2.,")=999,999.99 - НЕ ИСПРАВЛЕНА
5.
t=createObject("Table");
t.ИсходнаяТаблица("Таблица1");
t.getSection("aaa").area().text="abc";
//две следующие строки на случай, если все же не упадет
t.putSection("aaa");
t.show();
НЕ ИСПРАВЛЕНА
6.
Функция Выполнить6()
Шаблон("[Выполнить6()]");
КонецФункции
НЕ ИСПРАВЛЕНА, выход без сообщения об ошибки
7.
Процедура ПриРедактированииНовойСтроки()
УдалитьСтроку();
КонецПроцедуры
НЕ ИСПРАВЛЕНА
//-----------
PS: Нет предела совершенству.
<Тестирование производил Белов Сергей Васильевич aka Soaron, за что ему отдельное СПАСИБО!>

В 20-м релизе в Калькуляторе исправлена ошибка сложения положительного числа с отрицательным.
До сих пор было 10+(-10)=-20
<сообщил Reder>

Вот уже, если не ошибаюсь, 2 года работаем на 17 релизе SQL. Пробовали и 18-й, и 19-й, а вот теперь и 20-й. Самый первый глюк, который всплывает при переходе на очередной релиз - это баланс. Он сразу становится каким-то странным и отдельные значения итогов в упор не с теми же итогами, но выбранными каким-либо другим образом.
В общем, кто работает на 17-м релизе, сидите и не дёргайтесь: бесполезно. По крайней мере я говорю об SQL.
<сообщил Черноусов Виталий>

Насколько я понял, 20-й релиз сделали только для того, чтобы в список базовых конфигураций добавить "1С:Предприниматель"...
<сообщил Николай Малышевский>

Теоретически он должен поддерживать USB ключ.Но после неоднократных попыток заставить 20-й работать с USB ключом у нас так ничего и не получилось.
<сообщил Пименов Алексей>

Есть очень простая конфа на оперучете. Регистр заявки, где три измерения и один ресурс.
Отслеживаем, кому сколько должны товару по этим заявкам. Приходит клиент и говорит, вы мне отпустили столь-ко то рулонов бумаги в прошлом месяце. должны столько-то. Смотрю в отчет, должны меньше. Говорю нифига, мы вам отдали вот столь-ко. Клиент сопротивляется, у меня все на бумажке написано.
Щелкаю в отчете накладную, смотрю в нее, действительно, прав клиент. Отдали ему столько, сколько он сказал. Значит функция Расход() в запросе по регистрам на дбф базе работает не всегда правильно :-) Тут же открыл базу в 15-м релизе и о чудо! Данные в накладной и отчете совпали. Клиент доволен.
Это был первый и последний день моей работы с 20-м релизом.
<сообщил ЛеХа>

Релизы 20, 19, 18 для СКЛ. Конфигурация типовая для бюджетных организаций, рел. 4.14
Не работает запрос в документах ПоступлениеНаСчет и ПроходныйОрдер
ТЗ= "//{{ЗАПРОС(НайтиСуммуСтроки)
|с НачДата по КонДата;
|Без итогов;
|ТекущийДокумент = Документ.ПоступлениеНаСчет.ПервичныйДокумент.ТекущийДокумент, Документ.ПриходныйОрдер.ДокументОснования.ТекущийДокумент;
|СуммаДокумента = Документ.ПриходныйОрдер.СуммаДокумента, Документ.ПоступлениеНаСчет.Сумма;
|Функция СуммаДокументаСумма = Сумма(СуммаДокумента);
|Группировка ТекущийДокумент;
|Условие(ТекущийДокумент = ДокТ);
|"//}}ЗАПРОС
;
А под ДБФ все работает нормально.
<сообщил Bazil>

... запрос с выборкой периодических реквизитов, как не работал в 19-м, так и не работает в 20-м. А на 15-м все ок.
<сообщил Золушок>

?(1/1000000000000000000000 <> 0, 1, 0) = 1
1/1000000000000000000000 = 0
А вот так уже правильно (удален один ноль):
?(1/100000000000000000000 <> 0, 1, 0) = 1
1/100000000000000000000 = 0.00000000000000000001
<сообщил Serg1>

21 (вышел 09.06.2003)
Снята проблема с объединениями комплексных конфиг. под W2K, и глобальный поиск в конфигураторе на комплексной не вылетает.
Ну и конвертация в 8-ку еще.
<сообщил SergL>

Не знаю, пользовался ли кто при рисовании форм визардом создания элемента диалога - удобная штука, между прочим. Так вот, элементы, которые должны иметь "педальку" и создавались при помощи этого визарда, как раз таки этой педальки и не имели - надо было заходить в свойства. Теперь же все ОК. Мелочь, но приятно.
<сообщил С пивом по жизни>

Берем табличный документ, заполняем текст ячейки и расшифровку. Делаем поиск и замену. Если искомое значение встречается в РАСШИФРОВКЕ, вне зависимости от текста, после замены в расшифровку копируется содержимое текста ячейки!
Очень интересный облом может произойти в результате такой операции...
<сообщил panda>

21 стабильный...но ДВА неудобства...
1. При старте 1С, даже если ключ не найден, окно выбора баз появляется, а потом при выборе базы уже либо идет либо вылетает "..ключ защиты не обнаружен..."...можно по привычке проверить и уйти от клиента...а потом вернуться придется...
2. При удалении 21 релиза список баз ОЧИЩАЕТСЯ, даже если на машине остались другие релизы...
<сообщил Starican>

22 (вышел 20.05.2004)
...

Я думаю, что не ошибусь, попытаясь сформулировать общий принцип выбора релиза платформы, итак:
по сути дела, самым лучшим должен быть последний вышедший релиз и в большинстве случаев так оно и есть. Тем не менее, не стоит забывать и о том, что исправляя старые ошибки, разработчики добавляют новые. Поэтому, устанавливать только что вышедший релиз не рекомендуется - не известно, как он себя поведет (были случаи, что отдельные релизы "жили" всего две около двух недель, как например 16-й). После того, как он будет проверен другими пользователями (а такие будут, не сомневайтесь - новый релиз будут пробовать в первую очередь те, кого не устраивает работа существующих) и в Интернете появятся отзывы о работе релиза, хорошие или плохие, руководствуясь этими отзывами принимайте решение - обновлять или нет.
Следует отметить, что "Конфигуратор" корректнее работать всё-таки на последних релизах. При всяческих ошибках конфигурирования, приводящих к "падению" базы, хотлайн настоятельно рекомендует переходить на самый последний релиз.
Не стоит забывать и еще одно золотое правило "Работает - не трожь"...
Довольно часто работа релизов обсуждается на форуме "Территория 1С"


	На PORTA.ru ОГРОМНЫЙ выбор портативной техники: MD-плееры CD-плееры MP3-плееры Кассетные плееры Диктофоны Радио Цифр. камеры Сотовые Дешевые ноутбуки