В практике разработки на платформе 1С:Предприятие 8 существует классическая дилемма: использовать для построения отчетов данные из регистров или обращаться напрямую к табличным частям документов. С одной стороны, методология 1С и требования экзамена 1С:Специалист однозначно указывают на приоритет регистров. С другой — в таких сложных системах, как 1С:ERP 2.2/2.5, мы встречаем типовые отчёты (например, «Состояние выполнения»), которые читают данные из документов. Разберем эту ситуацию подробно, проанализируем риски и выясним, как правильно спроектировать отчет по заказам и отгрузкам.
Для начала вспомним, почему 1С настаивает на использовании регистров. Согласно требованиям аттестации, получение расчетных данных не из регистра считается серьезной ошибкой. Проанализируем основные причины этого правила:
РеализацияТоваровУслуг, и ОтчетОРозничныхПродажах. Отчету по регистру ВыручкаИСебестоимостьПродаж не важно, какой именно документ сделал запись.Проанализируем ситуацию с отчетом СостояниеВыполненияДокументов. Почему разработчики 1С отошли от собственных правил? Рассмотрим несколько причин:
Отображение состояний «вне учета». В ERP бизнес-процесс часто требует видеть состояние заказов, которые еще не проведены, находятся в статусе «Черновик» или на согласовании. В регистрах накопления таких данных просто нет, так как они попадают туда только в момент проведения.
Сложные статусы и флаги. Логика состояний в ERP (например, «Готов к обеспечению», «Закрыт», «Отменено») завязана на реквизиты шапки и строк документа. Чтобы не раздувать структуру регистров десятками служебных измерений, часть оперативной логики выносится на уровень документов.
Построчный анализ. Если отчет должен выводить специфические текстовые комментарии из строк документа или аналитику, которая не является ключевой для учета (и не включена в состав регистра), разработчикам приходится обращаться к первоисточнику — табличным частям.
Если мы решим последовать примеру этого отчета и построим свой общий отчет по Заказам клиентов и Заказам на перемещение через их табличные части, мы столкнемся с рядом проблем. Разберем их по шагам:
Деградация производительности. SQL-сервер отлично справляется с выборкой, когда база пустая. Однако через год-два, когда количество строк в таблицах ЗаказКлиента.Товары и ЗаказНаПеремещение.Товары достигнет сотен тысяч или миллионов, время формирования отчета вырастет экспоненциально. В отличие от регистров, у табличных частей часто отсутствуют необходимые индексы по полям, используемым в условиях (например, по произвольным реквизитам).
Блокировки данных. При чтении табличных частей в момент активной работы (когда другие менеджеры записывают новые заказы) могут возникать конфликты блокировок. Это замедлит работу всей системы, так как операции чтения будут конкурировать с операциями записи в одни и те же таблицы документов.
Если нам нужен аналитический отчет по всем заказам сразу (клиентов и перемещений), правильным подходом будет использование регистров накопления. Рассмотрим, как это реализовать.
В ERP для этих целей существуют универсальные регистры. Проанализируем ситуацию: данные о потребностях (заказах) и их обеспечении (отгрузках) обычно аккумулируются в регистрах:
ЗаказыКлиентов — для контроля остатков по заказам покупателей.ЗаказыНаПеремещение — для аналогичного контроля по внутренним заказам.ЗапасыИПотребности — наиболее универсальный регистр в последних версиях ERP, где сводятся данные по всем видам распоряжений.Разберем пример построения запроса к виртуальной таблице ОстаткиИОбороты регистра накопления. Это позволит нам увидеть и сколько было заказано (Приход), и сколько было отгружено (Расход).
ВЫБРАТЬ
ЗаказыОстаткиИОбороты.Заказ КАК ДокументЗаказа,
ЗаказыОстаткиИОбороты.Номенклатура КАК Номенклатура,
ЗаказыОстаткиИОбороты.КоличествоПриход КАК Заказано,
ЗаказыОстаткиИОбороты.КоличествоРасход КАК Отгружено,
ЗаказыОстаткиИОбороты.КоличествоКонечныйОстаток КАК ОсталосьОтгрузить
ИЗ
РегистрНакопления.ЗаказыКлиентов.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, Авто, , ) КАК ЗаказыОстаткиИОбороты
Для объединения данных по разным типам заказов (клиентов и перемещений) следует использовать оператор ОБЪЕДИНИТЬ ВСЕ, собирая данные из соответствующих регистров. Это будет работать в разы быстрее, чем попытка соединить огромные таблицы документов.
Если данных в существующих регистрах накопления не хватает для реализации специфической логики статусов, рассмотрим современный подход 1С: использование **Регистров сведений**. В последних версиях ERP многие состояния документов пишутся в специализированные регистры сведений (например, СостоянияЗаказовКлиентов). Чтение из индексированного регистра сведений всегда предпочтительнее, чем чтение из табличной части документа.
Подведем итог нашему анализу. Выбор источника данных зависит от задачи:
Помните: то, что в типовых конфигурациях встречаются отклонения от стандартов, часто обусловлено историческим наследием или экстремальной необходимостью визуализации. При разработке собственных механизмов всегда придерживайтесь правила: «Отчеты — по регистрам, формы документов — по данным объектов». Это обеспечит стабильную работу вашей системы на долгие годы.