Еще одна ошибка при работе платформы. На мой взгляд, это критическая ошибка, которую разработчики платформы не спешат исправлять. Почему — вопрос непосредственно в фирму 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С подкладывает ОЧЕНЬ большую свинью с косяком в выполнении запроса.
На сегодня все. Дальше будет больше и интереснее.