Рубрика: Ошибки в платформе 1С

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

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

Создаем документ с табличной частью. Создаем форму документа и размещаем на ней реквизиты, включая табличную часть. Теперь наша задача — отследить изменения пользователя реквизитов табличной части и по установленным нами правилами сделать пересчет служебных данных, проверки корректности заполнения и т.д.

И в этой ситуации мы выявляем небольшой косячок платформы 1С: если для поля табличной части определено событие «ПриИзменении» (и в соответствущей процедуре есть хоть одна строчка кода), то событие элемента табличной части «ПередОкончанием редактирования» не вызывается. От слова совсем.

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

На выявление этого косяка я потратил 30 минут. Печально, но это 1С и подобных косяков будет еще великое множество (на их официальном портале их тысячи неисправленных висит и никак не уменьшается).

Удачи вам в неравной борьбе с 1С.

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

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

Задача: необходимо получить ежедневные остатки и движения по товарам из регистра накопления с группировками «День, Номенклатура».

Исходные данные: регистр накопления (остатки) «Товары на складах» с измерениями «Склад, Номенклатура» и ресурсом «Количество».

Пишем простой запрос:

ВЫБРАТЬ
НАЧАЛОПЕРИОДА(ТоварыНаСкладахОстаткиИОбороты.Период, ДЕНЬ) КАК Период,
ТоварыНаСкладахОстаткиИОбороты.Номенклатура КАК Номенклатура,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоНачальныйОстаток) КАК КоличествоНачальныйОстаток,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоПриход) КАК КоличествоПриход,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоРасход) КАК КоличествоРасход,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток) КАК КоличествоКонечныйОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&ДатаНачала, &ДатаОкончания, День, ДвиженияИГраницыПериода, ) КАК ТоварыНаСкладахОстаткиИОбороты
СГРУППИРОВАТЬ ПО
ТоварыНаСкладахОстаткиИОбороты.Номенклатура,
НАЧАЛОПЕРИОДА(ТоварыНаСкладахОстаткиИОбороты.Период, ДЕНЬ)

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

В итоге мы получаем таблицу с неверными данными — точнее, неправильными остатками. Опишу на примере. Вот исходная таблица регистра:

Движение	Дата	Склад	Номенклатура	Количество
Приход	01.06.2020	СК1	Товар1	100
Приход	02.06.2020	СК2	Товар1	200
Расход	02.06.2020	СК1	Товар1	50
Расход	03.06.2020	СК2	Товар1	100

Теперь мы выполняем наш запрос с указанием периода с 01.06.2020 по 04.06.2020 и на выходе получаем табличку с такими данными:

Дата	Номенклатура	Ост. нач.	Приход	Расход	Ост. кон.
01.06.2020	Товар1	0	100	0	100
02.06.2020	Товар1	100	200	50	250
03.06.2020	Товар1	200	0	100	100
04.06.2020	Товар1	150	0	0	150

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

Будьте очень внимательны! Не наступайте на эти грабли!

Я на этот косяк (при выборке ежедневных остатков и движений) потратил 3 часа: на разбор полетов (поиск и выявление ошибки) и переделку алгоритма. Пришлось действовать по старинке — писать цикл со сборкой запроса «ОБЪЕДИНИТЬ», где в каждом подзапросе вытаскиваются остатки на одну дату. Так получилось дольше (по времени выполнения запроса), но зато данные верные.

Некоторые могут задаться вопросом — кому и на кой черт нужны остатки и движения с разбивкой по дням. Ответ — очень часто требуются такие данные для анализа товарных запасов, расчета автозаказа и, как ни странно, официальные представители больших контор требуют от дистрибьюторов данные о вторичных продажах и товарных запасов на складах и просят ежедневную выгрузку этих данных за последние 40 дней. А 1С подкладывает ОЧЕНЬ большую свинью с косяком в выполнении запроса.

На сегодня все. Дальше будет больше и интереснее.

Этой статьей начинаю описание ошибок, выявленных в 1С в процессе работы. Ошибки странные, если не сказать больше.

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

Ошибка в обработке условия в запросе.

Проблемный запрос:

ВЫБРАТЬ
СпрНоменклатура.Ссылка КАК Номенклатура,
РегистрПриоритет.Приоритет КАК Приоритет
ПОМЕСТИТЬ ВТ_Номенклатура 
ИЗ Справочник.Номенклатура КАК СпрНоменклатура 
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПриоритетыТоваров.СрезПоследних(&ДатаОкончания, ) КАК РегистрПриоритет
ПО (РегистрПриоритет.Номенклатура = СпрНоменклатура.Ссылка) И (ВЫБОР КОГДА РегистрПриоритет.ДатаОкончания = ДАТАВРЕМЯ(1, 1, 1) ТОГДА ИСТИНА ИНАЧЕ РегистрПриоритет.ДатаОкончания >= &ДатаОкончания КОНЕЦ) 
;
ВЫБРАТЬ
ВТ_Номенклатура.Номенклатура КАК Номенклатура,
ВТ_Номенклатура.Приоритет КАК Приоритет
ИЗ ВТ_Номенклатура КАК ВТ_Номенклатура
ГДЕ
ВТ_Номенклатура.Приоритет <> Значение(Перечисление.ВидыПриоритетов.Супер)

При выполнении этого запроса получается такая штука:

Ожидание: получить все записи, из справочника Номенклатура, у которых установлен приоритет, не равный значению «Супер» (в общем — записи из временной таблицы ВТ_Номенклатура, у которых приоритет равен пустой ссылке, NULL или любому значению кроме «Супер»).

Реальность: Получаем только те записи, у которых во временной таблице ВТ_Номенклатура поле «Приоритет» оказывается заполнено, т.е. значения NULL не попадают в итоговую таблицу, что очень странно, т.к. они не равны значению «Супер».

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