Вопросы
архитектуры системы 1С:Предприятие Вопросы
архитектуры системы 1С:Предприятие
Принципы
организации регистров оперативного учета
Компоненты
"Бухгалтерский учет" и "Оперативный учет" Отличия
и особенности использования.
Особенности
проведения документов оперативного учета
Принципы
организации бухгалтерских операций и проводок
Как текст запроса превращается
в выборку?
Объявление внутренних переменных
запроса
Формат хранения временных файлов
Структура записи таблицы выборки
Особенности
использования запросов
Общие положения написания запросов
Особенности использования запросов для получения информации из справочников
Определенная сложность освоения механизма регистров объясняется тем, что в отличии от проводок бухгалтерского учета, регистры оперативного учета не имеют аналогов в ручном учете и являются специфической моделью учета 1С:Предприятия.
В этом разделе приводятся разъяснения об организации механизма Регистров , являющихся основой компоненты 1С:Предприятия "Оперативный учет". Правильное понимание модели учета, поддерживаемой Регистрами необходимо для разработки конфигураций с использованием этой компоненты.
Прежде всего, следует различать использование регистров остатков и оборотных регистров. Не смотря на единство основных принципов, по своему назначению они существенно различаются.
Регистры остатков
Регистр остатков - это объект, предназначенный для учета наличия исчисляемых ресурсов в разрезе некоторого набора измерений. Ресурсами могут являться любые исчисляемые величины, такие как: "количество товара", "долг клиента", "сумма наличных" и т.п. Измерения Регистра остатков – это оси координат, на пересечении которых Регистр остатков хранит конкретные значения ресурсов. В качестве измерений могут выступать любые значения, характеризующие конкретные значения ресурсов, например, "материал", "место хранения", "организация".
Приведем пример регистра остатков. Допустим, у нас есть Регистр "ОстаткиТоваров", измерениями этого регистра являются: "Товар", "Склад", "МОЛ". Регистр имеет один ресурс - "Количество". Содержание данного Регистра можно представить в виде следующей таблицы, где по каждому конкретному товару на конкретном складе за конкретным МОЛ числится определенное Количество товара.
На рисунке приведена логическая схема хранения текущих остатков регистра "ОстаткиТоваров".
Под термином "остаток" ресурса следует понимать числовое значение, которое содержит величину ресурса на какой-то момент времени.
Для каждого регистра в информационной базе система хранит остатки на некоторые моменты времени и все движения по данному регистру.
Управление регистрами остатков осуществляется записью движений прихода и расхода в процессе проведения документа. Каждое движение содержит значения всех измерений и тех ресурсов, которые изменяются в данном движении.Алгебраическая сумма значений ресурсов имеющихся движений приходов и расходов и определяет состояние остатков, причем эти итоги формируются отдельно по каждой используемой комбинации значений измерений. Приведем пример движений регистра и остатков, которые получаются на основании этих движений:
Движения
Остатки
С помощью выполнения запроса или последовательного обхода движений можно получить различную информацию о суммах движений за некоторый период или детальных движениях. Итоги, хранимые регистром, предназначены для выдачи информации об остатках на определенный момент времени. Например, итоги
регистра "ОстаткиТоваов" позволяют ответить на вопрос: "сколько данного товара на этом конкретном складе числится за определенным материально-ответственным лицом".
Состав измерений регистров определяет максимальную детализацию хранения остатков. Разумеется, с помощью запросов можно "свернуть" остатки, получив их с меньшей детализацией. Свертка может производиться по любой комбинации измерений. Приведем некоторые варианты свертки регистра "ОстаткиТоваров".
Свертка по МОЛ.
Свертка по складу и МОЛ.
Свертка по товару и складу.
При проектировании регистра остатков следует придерживаться следующих правил:
Состав измерений регистра должен быть таковым, что для каждой единицы ресурса в конкретный момент времени можно однозначно определить значения всех измерений. В приведенном примере это означает, что каждая единица количества товара в конкретный момент располагается на некотором складе и при этом записана за определенным материально-ответственным лицом.
Движения регистров, выполняемые документами по регистру остатков должны выполнять как приход, так и расход по каждому используемому сочетанию значений измерений. Это означает, что нельзя допускать ситуации, когда в конфигурации предусматривается, например, запись движений прихода по некоторому сочетанию измерений регистра остатков и не предусматривается движений расхода по данному сочетанию значений измерений. Разумеется, приходы и расходы могут выполняться совершенно разными документами и в разные моменты времени, но сам принцип регистра остатков подразумевает то, что регистр отражает некоторый баланс наличия средств которые приходуются и расходуются. Причем данное правило должно выполняться для всех ресурсов регистра. В противном случае остатки регистра будут постоянно переноситься из периода в период и его использование будет неэффективным.
Кроме измерений и ресурсов в движениях регистров могут располагаться реквизиты. Они никак не влияют на расчет остатков. Реквизиты предназначены для указания в движениях некоторой дополнительной информации о выполненном движении. Например, при расходовании товара может указываться вид продажи (наличный или безналичный). Этот признак никак не влияет на остатки товаров, но может использоваться, например, для анализа структуры продаж.
Заметим, что если некоторое числовое значение является характеристикой движения регистра, и вы хотите получать по нему отчеты с суммами данного значения по движениям, но оно не имеет физического смысла в качестве остатка, то его следует вводить в структуру регистра в качестве реквизита, а не в качестве ресурса. Например, если при расходовании товара, мы хотим отразить сумму НДС, выделенную при продаже, но эта сумма не должна храниться в регистре в качестве остатка (так как мы не планируем вести учет остатков по НДС), то ее нужно ввести в структуру регистра в качестве реквизита.
Из описанных выше правил вытекает то, что регистр остатков фактически используется для организации некоторой замкнутой системы учета. Причем в определенной ситуации может существовать потребность в двух и более системах учета одних и тех же объектов предметной области. В этом случае создается более чем один регистр. Типичным примером использования нескольких регистров для учета одних и тех же объектов может служить учет складских запасов и резервирования товаров для тех случаев, когда резервирование выполняется не с конкретного склада, а от лица всей фирмы. При этом фактически ведется два учета - учет наличия товаров на складах и учет зарезервированных товаров по клиентам или конкретным счетам. На рисунке приведен пример такой структуры регистров.
Пример структуры регистров для учета товаров:
Регистр "НаличиеТоваров"
Регистр "РезервыТоваров"
Разумеется, в этом случае идентичность количественных остатков по товарам в обоих регистрах должна обеспечиваться синхронной записью движений по этим регистрам при проведении документов.
Для регистров остатков система обеспечивает хранение рассчитанных итогов и их динамическое обновление при любых действиях с движениями (записи движений, отмены проведения документов, удалении документов). Итоги хранятся системой на текущий момент (точку актуальности) и на границы предыдущих периодов. В качестве периода может выступать месяц, пятнадцать дней, декада и пять дней. Хранение текущих итогов позволяет системе выполнять быстрый доступ к итогам при проведении документов в реальном времени и для получения оперативных отчетов. Однако с помощью запросов или временных расчетов регистров существует возможность обращения к итогам на любой момент (любую дату или позицию документа). Для того, чтобы в этом случае не обрабатывать все существующие движения система использует хранимые итоги ближайшей границы периода и обрабатывает только движения от начала периода до указанного момента. Соответственно периодичность хранения определяет среднее время получения итогов на некоторый момент.
Чем меньше периодичность, тем меньше будет среднее время, но больше объем хранимой информации, и, соответственно, наоборот. Периодичность хранения итогов устанавливается в режиме управления оперативными итогами в режиме запуска "1С:Предприятие" и никак не влияет на функциональность системы, за исключением времени обращения к итогам на различные моменты и необходимости выполнения открытия периодов.
Оборотные регистры
В отличие от регистров остатков оборотные регистры призваны накапливать некоторые специфические итоги в разрезе периодов. То есть, ресурс оборотного регистра накапливает некоторую сумму за период. При этом значения измерений оборотного регистра детализируют накапливаемую сумму.
Примером оборотного регистра может служить регистр "ПродажаТоваров". Данный регистр учитывает объем продаж в разрезе товаров и клиентов.
На рисунке приведена логическая схема хранения итогов регистра "ПродажаТоваров".
Фактически итоги этого регистра позволяют ответить на вопрос "Сколько за определенный период продано данного товара конкретной организации". Разумеется, как и в случае регистра остатков, итоги оборотного регистра могут быть свернуты для получения данных с меньшей детализацией.
Таким образом, оборотный регистр может использоваться для накопления некоторых итогов в нескольких разрезах. В отличии от регистров остатков управление оборотным регистром осуществляется только одним видом движения, так как для оборотного регистра не имеет смысла понятия "приход" и "расход". Если, например, требуется получить данные и по продажам и по закупкам товаров, то можно либо создать два регистра, либо сделать два ресурса в одном регистре "Продано" и "Закуплено".
При создании конфигураций использование оборотных регистров обычно менее необходимо, чем регистров остатков. Часто, ту же информацию, которую можно получать из оборотного регистра, можно получить с помощью запроса из документов или из движений регистра остатков аналогичной структуры. Однако оборотный регистр позволяет получить накопленные данные с установленной периодичностью практически мгновенно, тогда, как получение их из движений или документов может потребовать значительных затрат времени. Вопрос о целесообразности использования оборотного регистра с точки зрения оптимизации должен решаться исходя из частоты выполняемых запросов и требований к их производительности.
Однако, одним из решающих аргументов для создания оборотного регистра может являться необходимость записывать в его движениях некоторый факт, который однозначно не содержится ни в документах, ни в движениях других регистров. В этом случае фиксация данного факта при проведении документа в оборотном регистре носит не оптимизационный характер, а является частью логики учетной схемы. Например, если в документе указываются комплекты товаров, а нам нужно получать отчеты по детальным продажам различным клиентам товаров входящих в комплекты, то использование оборотного регистра позволит при проведении документа сформировать движения с указанием организации - покупателя и конкретных товаров, входящих в купленные комплекты. Далее с помощью запросов мы сможем получить необходимую нам информацию о том, какой клиент, каких товаров сколько покупал за выбранный период.
Сами итоги оборотного регистра всегда хранятся и выдаются (объектом типа "Регистр") с детализацией до того периода, который задается в метаданных. Однако при выполнении запроса можно получить итоги и с любой другой периодичностью. Для оборотных регистров хранение итогов позволяет системе достаточно быстро формировать запросы по данному регистру за длительный интервал в разрезе той же периодичности, что и период оборотного регистра. Например, если периодичность регистра в метаданных выбрана - месяц, то запрос будет достаточно эффективно формировать итоги за два, три месяца и т.д. Обращение к итогам, например, за неделю потребует обработки движений регистра. Однако хранение итогов с маленькой периодичностью потребует достаточно больших ресурсов с точки зрения используемого дискового пространства.
Хронологический порядок документов и Точка Актуальности.
Для оперативного учета очень важной особенностью системы хранения документов 1С:Предприятия является то, что все документы (документы всех видов) располагаются в едином хронологическом порядке. Фактически он отражает последовательность событий хозяйственной жизни предприятия. Позиция документа в общей последовательности определяется его датой, временем, а также некоторой дополнительной величиной, которая устанавливает порядок документов с одинаковым временем в одной дате. Эта величина не регулируется пользователем, но система гарантирует ее неизменность. То есть, гарантируется, что при любых загрузках, выгрузках, перезаписях документы будут всегда находиться в одной и той же последовательности относительно друг друга, кроме случаев, когда у них редактируется дата или время. Заметим, что время документа служит в основном для упорядочивания их внутри даты и его связь с астрономическим временем весьма условна. То есть при изменении времени документа, для логики работы системы важна на сама смена значения времени, а изменение порядка документов.
Для компоненты "Оперативный учет" принципиальным понятием является "Точка Актуальности" (далее ТА). Вкратце ТА можно определить как точку на оси последовательности документов. Она может указывать на конкретный документ, или нет (например, если документ, на который она была установлена - удален), но она всегда выступает в качестве позиции на оси документов и любой документ в системе однозначно располагается либо до ТА, либо на ТА, либо после ТА. Точка актуальности является моментом, на который регистры содержат текущие значения всех ресурсов. Другими словами, если просто запросить у регистра значение какого либо ресурса, то он выдаст его именно на момент ТА. Если нам необходимо значение ресурса на прошедший момент времени, то надо либо сдвинуть в прошлое ТА (для этого используется операция "Управления итогами"), либо при помощи средств встроенного языка запустить "временный расчет" регистра.
Для регистров остатков итоги на ТА фактически отражают взаимоотношение приходов и расходов ресурса по каждому сочетанию измерений с момента начала ведения учета до момента ТА.
Для оборотных регистров итоги на ТА отражают накопленную сумму движений с ближайшего начала периода оборотного регистра до ТА. Для приведенного примера оборотного регистра итог на ТА будет означать количество проданного товара конкретному клиенту с начала месяца.
При нормальной работе Точка актуальности передвигается вперед в процессе последовательного проведения документов. Так как для регистров остатков итоги хранятся не только на текущий момент (то есть на ТА), но и на границы периодов (месяца, пятнадцати, десяти или пяти дней), то для проведения документа относящегося к следующему периоду необходимо выполнить открытие периода или перенос ТА на следующий период (эти действия однозначны). При этом система фиксирует хранимые остатки прошлого периода и инициализирует текущие остатки в новом периоде.
В системе программ 1С:Предприятие существует две функциональные компоненты используемые для автоматизации учета наличия и движения средств. Это компоненты "Оперативный учет" и "Бухгалтерский учет". Достаточно часто у специалистов занимающихся созданием и внедрением прикладных решений на базе 1С:Предприятия возникают вопросы связанные с сопоставлением функциональных возможностей этих компонент, а также их позиционированием. В этом разделе мы постараемся объяснить принципиальные различия этих двух компонент и дать рекомендации по их применению.
Основные принципы компонент
В начале приведем основные принципы, заложенные в эти компоненты.
Компонента "Оперативный учет" основана на механизме регистров. Регистр представляет собой многомерную систему учета наличия и движения средств. В конфигурации определяется набор независимых регистров. Каждый из них имеет собственную структуру, включающую набор измерений, образующих многомерную систему координат и набор ресурсов, определяющих состав собственно исчисляемых значений. При помощи регистров в конфигурации организуется достаточно сложный учет по конкретным разделам экономической деятельности предприятия. Причем структура регистров описывается в точном соответствии с необходимостью детализации по конкретным разделам учета . Например, для учета товаров минимально достаточно одного измерения - собственно "номенклатуры товаров". Дополнительно можно разделить учет по нескольким складам - тогда добавляется измерение "склад", можно ввести разделение по материально-ответственным лицам - ввести измерение "МОЛ". Если ввести партионный учет, то будет добавлено измерение "Партия". Состав измерений будет полностью определяться потребностями данного раздела учета. В некоторых случаях для учета товаров может быть введено два регистра, то есть учет товаров будет вестись в двух системах координат. Например, в этом может возникнуть необходимость, если нужно вести независимый учет резервирования товаров. Поясним это подробнее. Для любой единицы учитываемой в регистре должны быть однозначно определены значения всех измерений. Если резервирование производится не с конкретного склада, а для фирмы в целом , то для учета резервирования следует ввести отдельный регистр, который будет учитывать количество зарезервированного товара в разрезе покупателей и счетов на оплату. Таким образом, товары будут учитываться на одном регистре с точки зрения физического местоположения на складах, а на другом с точки зрения логического распределения по клиентам зарезервированных товаров. Состав ресурсов регистра также полностью определяется требованиями учета. Например, товары могу учитываться как в количественном выражении, так и в учетных ценах, для стоимостной оценки товарного запаса.
Важной особенностью компоненты "Оперативный учет" является ориентация на поддержку итогов в актуальном состоянии на текущий момент времени. Компонента "Оперативный учет" поддерживает остатки регистров на "Точку актуальности", которая при повседневной работе соответствует последнему проведенному документу. При проведении документы располагаются в именно порядке проведения, а не в порядке ввода, что обеспечивает четкую последовательность отражения в учете деятельности предприятия.
Доступ к текущим остаткам регистров осуществляется практически мгновенно. Это позволяет при проведении документов контролировать наличие товаров на складах, состояние взаиморасчетов и другие данные именно на момент проведения документов. Мгновенный доступ к текущим итогам при проведении документов позволяет исключить одновременное списание со склада одних и тех же товаров разными менеджерами.
Компонента "Бухгалтерский учет" обеспечивает ведение планов счетов, операций, проводок и бухгалтерских итогов. Она ориентирована на отражение хозяйственной жизни предприятия именно в бухгалтерском учете. То есть, она реализует основные принципы бухгалтерского учета.
Прежде всего, весь учет обязательно ведется в разрезе синтетических счетов . Все остальные разрезы учета (субсчета, валютный учет, аналитический учет) выступают, как дополнительные, и могут не использоваться. Учет может вестись в денежном и натуральном выражении. При ведении валютного учета отдельно также учитываются валютные суммы.
Вся информации о движении средств отражается в проводках. Все проводки имеют одинаковую структуру, а состав данных в них определяется настройками учета корреспондирующих счетов. Так для счета может быть определено до 5 разрезов аналитического учета. Соответственно значения объектов аналитики в проводках будут заполнены в том объеме, который определен для конкретного счета. Многомерность аналитики позволяет, например, для счета 10 (материалы) организовать учет в разрезе номенклатуры, мест хранения и материально-ответственных лиц.
Так как одним из основных принципов бухгалтерского учета является принцип двойной записи, проводка имеет дебетовую и кредитовую часть. В некоторых случаях одна из частей может быть не заполнена, например, при использовании забалансовых счетов.
Система хранения бухгалтерских итогов ориентирована на быстрое получение итогов с детализацией до месяца, то есть данных об остатках на начало месяца, оборотах за месяц, остатках на конец месяца, а также по любым периодам, состоящим из целых месяцев. Получение итогов может производиться за любой интервал и на любой момент времени, но это выполняется системой за счет дополнительной обработки проводок.
Сопоставление средств и возможностей компонент
Теперь сопоставим средства, используемые этими компонентами, и возможности, которые они предоставляют.
На первый взгляд компоненты "Бухгалтерский учет" и "Оперативный учет" решают практически одну и ту же задачу, но разными способами. На самом деле различия между ними весьма существенные.
Первое отличие компонент заключается в механизме отражения информации о движении средств. В компоненте "Бухгалтерский учет" основным разрезом учета являются синтетические счета, которые и определяют бухгалтерскую модель отражения хозяйственной деятельности предприятия. В компоненте "Оперативный учет" механизм регистров является более универсальным средством и не имеет предопределенных разрезов учета.
Многомерный аналитический учет в 1С:Бухгалтерии действительно позволяет так же как и регистры оперативного учета хранить данные о движении средств и получать итоги в различных разрезах. Однако он предназначен для детализации итогов по синтетическим счетам. Тогда, как регистры оперативного учета представляют собой самостоятельную универсальную модель многомерного учета.
Использование аналитики в бухгалтерском учете в сравнении с регистрами менее гибко и менее эффективно при сложном учете и большом объеме информации. Это определяется единообразным хранением всех проводок. Устройство регистров позволяет максимально точно отразить в них требуемую схему учета по конкретным разделам, что обеспечивает наиболее эффективное хранение и использование информации. Кроме того, при использовании версий 1С:Предприятия для SQL механизм регистров более эффективно оптимизируется системой за счет того, что структура хранения информации регистров более точно соответствует типовым структурам баз данных, чем универсальные структуры используемые для хранения данных о
бухгалтерских проводках и итогах.
Механизм регистров не использует понятие "двойной записи", так как оно предназначено именно для бухгалтерского учета, то есть для отражения финансового состояния предприятия в денежном выражении как с точки зрения наличия средств, так и с точки зрения источников финансирования и финансовых обязательств.
Другим различием механизмов бухгалтерского и оперативного учета в 1С:Предприятии является распределение во времени совершения хозяйственных операций на предприятии и отражения их в учете. Работа бухгалтерии, как правило, ведется "по факту". То есть в бухгалтерию поступает информация о совершенных операциях, которая отражается в бухгалтерском учете. Причем это может производиться со значительным запозданием. То есть бухгалтер заносит данные о совершении хозяйственных операций, как летописец освещает произошедшие события. Соответственно компонента "Бухгалтерский учет" ориентирована на ввод операций за любые даты и быстрое получение итогов с детализацией по месяцам и кварталам, что весьма необходимо для составления отчетности.
Компонента "Оперативный учет" напротив предназначена для отражения хозяйственных операций в основном непосредственно в момент их совершения, то есть в реальном времени. Понятие "точки актуальности" (текущего момента) позволяет не просто отражать в учете операции в момент их совершения, но и выполнять различного рода контрольные действия по определению правомерности совершения операций (контроль наличия товаров, состояния взаиморасчетов). Для этого в механизме регистров оптимизировано получение итогов именно на текущий момент, то есть на момент совершения хозяйственной операции. Разумеется, существует возможность изменения уже введенной информации и ввода информации "задним числом", но она используется в основном как исключение, для исправления ошибочно введенных ранее данных.
Важным аспектом для понимания разницы между бухгалтерским и оперативным учетом в 1С:Предприятии является тот факт, что устройство операций и проводок в бухгалтерском учете ориентировано на непосредственную работу с ними конечного пользователя. Бухгалтер понимает, как устроен учет на уровне синтетических счетов, аналитики, проводок и итогов. Он может вводить проводки вручную, может настраивать ведение учета, может самостоятельно интерпретировать проводки, записанные документами и
стандартные отчеты. Таким образом бухгалтерский учет в 1С:Предпрятии реализован понятными бухгалтеру категориями ("счет", "субсчет", "аналитика", "валюта", "проводка").
Регистры оперативного учета выступают в качестве внутреннего механизма, который используется при конфигурировании системы. Пользователь (продавец, менеджер) не посвящается в подробности реализации учета. Он работает с документами и отчетами, а механизм регистров, который при этом фактически используется, обеспечивает получение необходимой информации, но скрыт в конфигурации. При использовании механизмов оперативного учета конечному пользователю не предоставляется универсальных
средств отражения операций в регистрах и получения отчетов. Все предусмотренные варианты движения регистров и получения итогов описаны в конфигурации в виде документов и отчетов и предназначены для вполне конкретного использования. Например, для отражения движений товаров вводится несколько видов документов (накладных, требований), а для получения итогов один или несколько отчетов (материальная ведомость, карточка товара и т.д.). Работа пользователя с бухгалтерским учетом предусматривает как специализированные режимы (документы, отчеты) ориентированные на конкретные разделы учета, так и универсальные средства отражения любых хозяйственных операций (операции вводимые вручную, типовые операции) и универсальные средства получения итогов по любым разделам учета (стандартные отчеты).
Заметим также, что конфигурирование механизма регистров обычно выполняется специалистами по автоматизации, тогда как конфигурирование компоненты "Бухгалтерский учет" в категориях понятных бухгалтеру позволяет выполнять настройку учета и специалисту имеющему экономическое образование и небольшие навыки работы с компьютером. Такое различие объясняется тем, что сам механизм бухгалтерского учета существовал фактически как некоторая универсальная математическая модель со времен Луки Почиоли, еще задолго до появления компьютеров и знаком бухгалтеру, тогда как регистры оперативного учета являются специфическим механизмом 1С:Предпряития.
Рекомендации по использованию компонент.
Теперь постараемся подытожить приведенные отличия компонент и дать рекомендации по их применению.
Очевидно, что компонента "Бухгалтерский учет" идеально подходит для ведения синтетического учета и аналитического бухгалтерского учета. Мощные возможности аналитического учета позволяют также использовать ее для ведения управленческого складского учета, взаиморасчетов, учета в производстве и т.д. Все разделы поддерживаются единым механизмом проводок, который обеспечивает высокую наглядность отражения в учете операций для бухгалтера. Механизм аналитического учета целесообразно использовать в тех случаях, когда он необходим для получения развернутых итогов по синтетическим счетам и для составления бухгалтерской и налоговой отчетности.
Компонента "Оперативный учет" позволяет построить весьма специфичную схему учета в соответствии с конкретным разделом учета. Ее целесообразно использовать при сложном управленческом учете и большом объеме хозяйственных операций. Как правило, она применяется для автоматизации основной деятельности предприятия. Например, в торговле это учет наличия и движения товаров, учет взаиморасчетов с клиентами, а в производстве – учет материалов, выпуска готовой продукции, калькуляции затрат. Гибкая
настройка механизма регистров позволяет эффективно поддерживать сложные виды учета, например, учет заказов, учет товарных кредитов, учет товаров на реализации, списание по методам LIFO/FIFO и т.д. Компоненту "Оперативный учет" целесообразно также применять в тех случаях, когда автоматизированную систему предполагается использовать в реальном времени. То есть не только для фиксации в учете произошедших хозяйственных операций, но и для получения оперативной информации о текущем состоянии материальных и денежных средств, и принятия с помощью программы управленческих решений, например, обеспечения контроля одновременного доступа к товарным запасам нескольких пользователей.
То есть механизмы компоненты "Бухгалтерский учет" наиболее эффективны именно как средство отражения хозяйственной деятельности в соответствии с требованиями методологии бухгалтерского учета. Средства "Оперативного учета" предназначены не только для отражения, но и для управления собственно совершением хозяйственных операций.
Наибольший интерес представляет совместное использование компонент. На практике на предприятии с одной информационной базой могут работать и сотрудники бухгалтерии, и менеджеры (например, отдел продаж, коммерческий отдел). Использование в одной конфигурации компонент "Оперативный учет" и "Бухгалтерский учет" позволяет органично совместить работу различных подразделений. Механизмами оперативного учета решаются задачи собственно управленческого учета, составляющие основной объем хозяйственных операций на предприятии и ведущихся в реальном времени. Средствами оперативного учета отслеживаются движения товаров, складские запасы, выполняется резервирование, поддерживаются взаиморасчеты с клиентами с учетом кредитов, консигнации и других особенностей управленческого учета. Все операции, реализуемые компонентой "Оперативный учет" полностью описываются в конфигурации, так как персонал, который их оформляет не должен иметь возможность отклонения от принятой схемы ведения бизнеса и, как правило, не осведомлен об особенностях реализации учетных регистров.
По данным управленческого учета могут автоматически формироваться проводки для отражения определенного круга операций в бухгалтерском учете. Причем отражение в бухгалтерском учете целесообразно выполнять с той степенью подробности, которая необходима для получения бухгалтерской и налоговой отчетности. То есть информация о хозяйственных операциях будет "сворачиваться", освобождаясь от деталей несущественных для бухгалтерского учета. Например, очевидно, что для бухгалтерии несущественно распределение товаров по складам. Кроме того, и сама детализация по конкретным товарам также может не отражаться в бухгалтерском учете. Кроме отражения данных полученных на основании оперативного учета, компонента "Бухгалтерский учет" используется для автоматизации самых разных разделов учета предприятия не имеющих большой нагрузки по количеству операций и не требующих участия программы в управлении операциями. Например, это взаиморасчеты с подотчетными лицами, учет основных средств и т.д. Разумеется, компонента "Бухгалтерский учет" используется также для определения финансовых результатов, составления бухгалтерской и налоговой отчетности. В отличии от оперативного учета компонента "Бухгалтерский учет" допускает ручной ввод операций. Это возможно благодаря тому, что бухгалтер владеет понятиями, которыми оперирует программа (счет, аналитика, проводка и т.д.). Возможность ручного ввода операций позволяет отражать разовые операции, не предусмотренные конфигурацией, что зачастую проще и эффективнее, чем внесение изменений в конфигурацию.
Таким образом определяющими факторами для выбора используемых компонент 1С:Предприятия для автоматизации учета в конкретной организации является состав задач, круг пользователей, и режим отражения в учете хозяйственных операций. Если систему предполагается использовать только в бухгалтерии для занесения данных о хозяйственных операциях и получения внутренней и внешней отчетности, то достаточно применения компоненты "Бухгалтерский учет". Если предполагается автоматизировать исключительно управленческий учет (работу менеджеров по управлению закупками, продажами, складскими запасами, взаиморасчетами), то целесообразно использовать только компоненту "Оперативный учет". Если предполагается автоматизировать оба этих направления во взаимосвязи, то следует задействовать и ту и другую компоненту в единой конфигурации.
При проектировании конфигурации 1С:Предприятия весьма важным моментом для понимания является процесс проведения документа.
Фактически документ в системе 1С:Предприятие являются объектом отражающим в информационной базе некоторое событие произошедшее в хозяйственной жизни предприятия (оприходование товара, получение денег от покупателя, оформление отпуска сотруднику, переоценка валютных остатков и т.д.). Структура данных документа должна отражать различные характеристики конкретного события. Документы, как объекты прикладной задачи, тесно связаны с различными учетными механизмами 1С:Предприятия. Причем эта связь проявляется именно в процессе проведения документа. Некоторые документы вообще могут не использовать механизм проведения. В этом случае они используются просто как средство регистрации события и печати формы первичного документа. Для таких документов, рекомендуется отключить признак проведения в свойствах документа в метаданных. Однако для большинства видов документов выполняется проведение для того, чтобы отразить событие в различных учетных механизмах 1С:Предприятия.
При проведении документа сама система только помечает его как проведенный. Собственно все действия документа при проведении описываются в конфигурации в модуле документа в процедуре "ОбработкаПроведения" на встроенном языке. В принципе в этой процедуре можно описать практически любые изменения в информационной базе. Однако механизм проведения документов предназначен для выполнения вполне определенных действий:
- Запись значений периодических реквизитов справочников, для которых установлена возможность изменения документами;
- Запись движений регистров оперативного учета;
- Запись данных в журнал расчетов;
- Запись бухгалтерских операций и проводок.
Заметим, что все перечисленные действия должны выполняться специальными средствами, ориентированными именно на использование в процессе проведения документа. Например, запись значения периодического реквизита справочника должна выполняться методом "УстановитьРеквизитСправочника", а не методами объекта "Периодический".
Важно понимать, что одной из главных особенностей механизма проведения документа является фиксация всех перечисленных действий и возможность их автоматического аннулирования при отмене проведения документа, при его перепроведении и при удалении документа.
То есть все перечисленные действия записываются в информационную базу с привязкой к документу. Это позволяет не только посмотреть, какой документ выполнил конкретные действия, но и произвести их аннулирование и повторное воспроизведение. Например, если документ при проведении записал бухгалтерскую операцию с проводками то при его перепроведении ранее сформированные проводки автоматически удаляются и вычитаются из бухгалтерских итогов а новые записываются и вновь отражаются в итогах. То есть это позволяет автоматически изменять влияние события отражаемого документом на различные механизмы 1С:Предприятия.
Для механизмов бухгалтерского и оперативного учета действия, выполняемые при проведении документа, не только привязываются к документу, но и используют документ в качестве момента выполнения действий. То есть и для регистров и для бухгалтерских итогов порядок следования документов определяет порядок отражения движений и проводок в учете. Соответственно итоги и оперативного и бухгалтерского учета могут быть получены на момент конкретного документа.
Рекомендуется в алгоритме проведения документа не выполнять иных изменений в информационной базе кроме тех, которые приведены выше. Это объясняется тем, что все остальные действия, выполненные в процессе проведения, не будут привязаны к документу, то есть не будут автоматически аннулироваться при отмене проведения документа или его перепроведении.
Модуль документа может содержать две предопределенные процедуры "ОбработкаПроведения" и "ОбработкаУдаленияПроведения". В отличии от всех других предопределенных процедур 1С:Предприятия, которые в основном предназначены для специфической обработки интерактивных действий пользователя, эти две процедуры вызываются всегда при выполнении проведения и отмене проведения документа, вне зависимости от того, происходит это интерактивно или из встроенного языка.
Эти процедуры вызываются в автоматически открываемой системой транзакции вместе с собственно проведением и отменой проведения, что позволяет однозначно логически увязать действия, выполняемые в данных процедурах, с самим фактом пометки документа как проведенного и снятия этой пометки.
Следует учитывать, что если в ходе выполнения этих процедур выполняется изменение значений реквизитов документа, то по окончанию выполнения процедуры эти изменения будут записаны. Причем запись будет выполняться в той же транзакции.
Процедура "ОбработкаУдаленияПроведения" выполняется и в случаях удаления и пометки на удаление документа, то есть при любых случаях, когда отменяются выполненные документом при проведении действия, кроме случая перепроведения документа, так как при проведении выполняется процедура "ОбработкаПроведения".
Наличие предопределенной процедуры "ОбработкаУдаленияПроведения", позволяет в отдельных случаях организовать автоматическое аннулирование некоторых дополнительных изменений в информационной базе, которые выполняются в процессе проведения. Однако организация такого алгоритма требует особой аккуратности и хорошего понимания выполняемых действий. В общем случае, рекомендуется выполнять при проведении документа только перечисленные выше изменения в информационной базе, которые система сможет автоматически контролировать при любых действиях с документом. При использовании в процедуре проведения только специализированных средств изменения информационной базы написания предопределенной процедуры "ОбработкаУдаленияПроведения" не потребуется. В то же время, она может быть создана для контроля правомерности отмены проведения документа.
Таким образом, действия, которые должны быть логически жестко увязаны с проведением документа или отменой проведения нужно размещать именно в процедурах "ОбработкаПроведения" и "ОбработкаУдаленияПроведения" модуля документа, а не в предопределенных процедурах, обрабатывающих, например, интерактивные действия пользователя в журналах документов.
В версии 7.7 введена дополнительная возможность управления процессом проведения. В метаданных свойствах документа может быть отключен автоматический режим удаления движений в процессе проведения и отмены проведения. Отключение режима автоматического удаления движений рекомендуется выполнять в специальных случаях, так как очевидно, что это потребует более сложного написания модулей. Следует заметить, что отключение автоматического режима удаления не нарушает основной концепции проведения документов. Главным отличием этого варианта является то, что появляется возможность в процессе проведения уже проведенного документа записывать движения не "с чистого листа", а дописывать к созданным при прошлом проведении. А само удаление движений может быть выполнено в процессе перепроведения вызовом специального метода. При отмене проведения, разумеется, движения документа удаляются в любом случае. Разница заключается лишь в том, что при, выключенном режиме автоматического удаления движений, движения реально удаляются системой не до выполнения предопределенной процедуры "ОбработкаУдаленияПроведения", а после.
Проведение документов, относящихся к оперативному учету, имеет ряд особенностей, которые необходимо учитывать, как при создании конфигурации, так и при администрировании работы пользователей. Идеология механизмов компоненты "Оперативный учет" предполагает преимущественно последовательный ввод и проведение документов. Проведение документов "задним числом" должно осуществляться как исключение и обрабатывается системой отдельно.
Рекомендуется изменение и проведение документов задним числом рассматривать в качестве исправления ошибочно введенных или не введенных данных в информационной базе. То есть изменение и проведение документа задним числом должно производиться с целью приведения информационной базы в соответствие с реально произошедшими событиями, а не внесения произошедших позднее событий в качестве изменений в более ранние документы. Например, если выяснилось, что вчера на складе был оприходован товар, но не была введена соответствующая приходная накладная, то такой документ следует ввести задним числом, так как реально событие уже произошло. Аналогично можно исправить неверно заполненную приходную накладную, если оказалось, что на самом деле товаров было оприходовано больше, чем введено в документе . Если же сегодня осуществляется возврат товара от покупателя, проданного вчера по расходной накладной, то неверным будет исправление введенной расходной накладной (уменьшение количества отпущенного товара с учетом возврата). Заметим, что при этом остаток товаров на складе на утро текущего дня будет неверным. Правильно будет ввести текущей датой документ, отражающий возврат товара покупателем. В этом случае порядок следования и содержание документов в информационной базе будет соответствовать последовательности и содержанию событий хозяйственной жизни предприятия и это позволит реально восстановить картину учета на любой момент времени.
Так как запись и проведение документов может выполняться раздельно, в системе предусмотрен механизм обеспечивающий расположение документов не в порядке их записи, а в порядке проведения. Это позволяет обеспечить проведение всех документов в реальном времени, то есть с обращением в процессе проведения к текущим остаткам регистров. Ключевым моментом в этом механизме является точка актуальности (ТА), отражающая обычно позицию последнего проведенного документа, то есть последнее событие в хозяйственной жизни предприятие, зафиксированное в информационной базе.
Соответственно регистры оперативного учета отражают наличие различных средств на этот момент, или точнее "по этот момент", так как движения документа стоящего на ТА включается в текущие остатки регистров.
В процессе проведения документа пользователем из формы документа система распознавая возможность появления конфликтных ситуаций, выдает пользователю сообщения-запросы, чтобы корректно разрешить возможный конфликт. Таких ситуаций может быть три:
Рассмотрим подробнее эти ситуации. На приведенных ниже схемах обозначена ось времени с отметками моментов перехода на новую дату, времени Точки
Актуализации (ТА), времени ввода нового документа ( Новый документ ).
Значком 
на схемах обозначены
существующие проведенные документы.
Значком
на схемах обозначены
новые документы, которые проводятся.
Значком
на схемах обозначены
существующие проведенные документы, которые
находятся за моментом ТА (они не учтены в остатках регистров).
На рисунке приведена схема ситуации, когда документ проводится задним числом, дата документа меньше даты ТА и между документом и ТА существуют ранее проведенные документы.
Время документа в 1С:Предприятии служит в основном для расстановки документов в определенном порядке, а не для отражения астрономического времени ввода документа. Поэтому при проведении документа время может быть исправлено. Однако дата документа является его важным реквизитов и не исправляется системой автоматически.
Так как в данном случае дата документа меньше ТА, то система не может обеспечить проведение данного документа в реальном времени. В этом случае система выдает следующее сообщение:
"Дата документа меньше ТА! Провести документ задним числом ?"
Данным сообщением программа предупреждает пользователя, что проведение документа нарушает естественную последовательность ввода документов. Если алгоритм Модуля движения регистров данного документа предусматривает данную ситуацию, например, запускает временный расчет регистров, или для данного документа эта ситуация не является конфликтной (например для выписки приходной накладной не анализирующей текущие остатки регистров), то можно нажимать кнопку "Да". В противном случае, когда правильность проведения нового документа зависит от временной последовательности проведения документов, следует нажимать кнопку "Нет". Тогда документ будет записан, но не проведен. В дальнейшем можно будет провести данный документ в режиме группового проведения, используя операцию "Управление итогами", откатив ТА назад, а затем снова вперед с одновременным перепроведением документов. При групповом проведении документы проводятся последовательно, в естественном временном порядке с получением текущих итогов регистров.
Решение, которое должен принимать пользователь, зависит от конкретной конфигурации и алгоритма проведения конкретного документа. Поэтому мы рекомендуем, по возможности, предусматривать в алгоритмах проведения документов обработку ситуаций проведения документов задним числом или ограничить возможность пользователей проведения документов задним числом.
На рисунке приведена схема ситуации, когда документ проводится той же датой, что и дата ТА, но время документа меньше времени ТА и между документом и ТА существуют ранее проведенные документы.
В этом случае система выдает следующее сообщение:
"Время документа меньше точки актуальности. Существуют более поздние проведенные документы."
Пользователю предлагается выбрать один из двух вариантов:
Данным сообщением программа предупреждает пользователя, что проведение документа нарушает естественную последовательность ввода документов в пределах одной даты. Пользователю предлагается сделать выбор: или принять решение, чтобы система изменила время документа так, чтобы он стал последним среди проведенных документов, или провести документ без изменения времени, то есть задним числом. По умолчанию предлагается изменить время документа .
Как уже отмечалось, компонента оперативного учета предполагает последовательный ввод и проведение документов, поэтому данный вопрос системы позволяет автоматически перенести документа за точку актуальности в процессе проведения, то есть провести его в актуальном состоянии.
Выбор пользователя в данном случае должен определяться тем, отражает ли данный документ событие, происходящее в данный момент времени, или он отражает событие произошедшее в начале дня (в более раннем времени) и по ошибке не нашедшее отражение в системе.
Наиболее типовым случаем, когда выдается данный вопрос, является ситуация, при которой пользователь записал новый документ, но перед тем как он начал его проводить, другим пользователем был проведен более поздний документ.
Так как событие документа фактически отражается им в регистрах в момент проведения, разумеется, для соблюдения последовательность проведения документов следует выбирать вариант "Изменить время документа".
Вариант "Провести документ задним числом" следует выбирать в том случае, когда документ умышленно помещен до точки актуальности, и он отражает событие, которое произошло ранее событий отраженных более поздними проведенными документами.
Следует заметить, что параметры системы, настраиваемые пользователем в закладке "Оперативный учет" режима "Параметры", позволяют установить режим, при котором данный вопрос выдаваться не будет. Проведение документа с переносом его за ТА будет выполняться автоматически при проведении новых документов в текущей дате. Кроме того, существует возможность установить параметр, который будет автоматически выбирать время записи нового документа более поздним , чем ТА . Это позволит уменьшить вероятность возникновения описанной ситуации, даже при сильных расхождениях таймеров компьютеров пользователей, так как новые документы будут записываться не с текущим временем компьютера, а после ТА.
Кроме того, существует возможность регулировать проведение документов (проводить в реальном времени или задним числом) в модуле формы документа средствами встроенного языка (при использовании метода "Провести"). В этом случае, существует специальная возможность проводить в реальном времени уже проведенный документ. При этом, фактически, обеспечивается перепроведение документа в реальном времени (с переносом его за ТА). Очень важно, что в этом случае и удаление существующих движений и формирование новых выполняется в единой транзакции. Например, в типовой конфигурации "Торговля и склад" (редакция 8) этот механизм используется для предварительного проведения расходной накладной. Фактически, пользователь может несколько раз выполнять проведение документа в текущей дате в реальном времени. Если бы он распроводил документ и проводил заново, то существовала бы вероятность того, что другой пользователь отгрузит "дефицитный" товар и повторное проведение уже не будет выполнено. При перепроведении в реальном времени, другие пользователи не могут "вклиниться" между удалением движений и формированием новых.
Приведенная на рисунке схема отражает ситуацию, когда документ проводится после ТА, но между проводимым документом и ТА уже есть ранее проведенные документы.
В этом случае система выдает следующее сообщение:
"Существуют более ранние проведенные документы!"
Этим сообщением программа предупреждает пользователя о том, что проведение документа сейчас невозможно, т.к. в данном случае проведение документа должно подразумевать сдвиг ТА вперед с зачислением в регистры движений ранее проведенных документов. Но такой процесс, должен производиться только в режиме "Управления оперативными итогами" или операцией "Установить ТА на документ". Поэтому в данном случае документ не проводится.
Данная ситуация может произойти только в случае, если ранее был выполнен процесс переноса ТА назад и некоторые проведенные документы оказались после ТА. Так как на практике перенос ТА назад выполняется только в специальных целях и обычно администратором системы, то, очевидно, не следует допускать ситуации, чтобы при начале работы пользователей система находилась в таком состоянии. То есть после переноса ТА назад и выполнения необходимых действий администратору следует либо последовательно провести документы после ТА, либо передвинуть ТА вперед на последний проведенный документ.
При написании модуля оперативного документа следует учитывать, что использование текущих итогов регистра в процессе проведения может выполняться только если метод "ИтогиАктуальны" возвращает значение "1". При этом обращение к текущим итогам может выполняться методами объекта "Регистр" или объектом "Запрос" с периодом без указания конечной границы.
Если метод "ИтогиАктуальны" возвращает "0", то при использовании объекта "Регистр" следует выполнять временный расчет на текущий документ, а при использовании объекта "Запрос", следует указывать в качестве конечной границы текущий документ.
Кроме того, при написании алгоритма проведения в некоторых случаях следует учитывать, что проведение может выполняться в процессе группового проведения (метод "ГрупповаяОбработка"). Например, в этом случае, очевидно, не следует выполнять проверку наличия товара на складе и прерывать проведение, если текущее количество товаров не соответствует затребованному, так как документ уже был оформлен и должен быть перепроведен в соответствии с указанными данными. Проверки текущего наличия товаров, обычно, имеют смысл при текущей работе пользователей, чтобы исключить продажу закончившегося товара.
При освоении средств конфигурирования 1С:Предприятия одним из частых вопросов, которые требуют дополнительного разъяснения является вопрос об общих принципах организации в системе бухгалтерских операций и проводок. Часто этот вопрос возникает у тех специалистов, которые знакомы с принципами организации регистров оперативного учета. Действительно, проводки бухгалтерского учета имеют много общего с движениями регистров. Однако, движения регистров подчиняются непосредственно документу, а для проводок существует понятие "Операция", объединяющая проводки сформированные одним документом. Наличие понятия операции объясняется несколькими причинами, связанными с назначением и практикой использования компоненты "Бухгалтерский учет".
Очень важным отличием механизма бухгалтерского учета от механизма оперативного учета является то, что механизм операций и проводок наряду с автоматическим формированием проводок документами рассчитан на ведение учета вручную. Это возможно благодаря тому, что сама модель бухгалтерского учета (проводки, двойная запись, счета синтетического учета, аналитика) доступна пользователю (бухгалтеру) и программа может общаться с ним именно в тех категориях, в которых и ведется учет. Для оперативного учета это не так. Пользователь не работает напрямую с регистрами, так как механизм оперативного учета не является "общечеловеческим" понятием, а разработан как специализированное средство 1С:Предприятия. Наличие в метаданных понятия "Операция" позволяет обеспечить, для ведения ручного учета возможность удобного ввода проводок в специализированной форме, которая также как и большинство форм в 1С:Предприятии может быть изменена разработчиком конфигурации.
Заметим, что назначение регистров оперативного учета, может быть самое различное. Каждый регистр представляет собой фактически независимую учетную систему. Иногда один или два регистра могут быть логически связаны, но в то же время могут использоваться регистры, которые предназначены для отражения некоторого факта хозяйственной жизни в совершенно разных учетных задачах поддерживаемых конфигурацией. Проводки бухгалтерского учета, как правило, относятся к одному плану счетов и являются отражением хозяйственной операции в одной учетной системе описываемой планом счетов. Таким образом, проводки сформированные документом или введенные вручную в одной операции представляют собой обычно нечто большее, чем просто набор отдельных движений. Понятие "Операция" позволяет объединить все проводки формируемые документом или вводимые вручную. В отличии от движений регистров, которые с помощью соответствующего объекта встроенного языка могут только записываться и считываться по одному движению, все проводки операции считываются при обращении к операции. Затем с ними могут выполняться различные действия, например, можно изменять, добавлять и удалять проводки. Измененная операция записывается целиком.
Пожалуй, одной из самых важных задач операции является возможность вводить для операции реквизиты. Для оперативного учета практически не имели бы смысла, какие либо данные, которые относились бы ко всем документам, записывающим движения регистров. Однако для бухгалтерского учета эта задача вполне актуальна. С точки зрения бухгалтера, все операции (и введенные вручную и сформированные документами) являются равноценными записями, отражающими хозяйственную операцию в бухгалтерском учете. И у этой записи должны быть некоторые данные, характеризующие ее в целом. Наиболее яркими примерами таких данных являются "штатные" реквизиты операции ("Содержание" и "Сумма операции"). Когда бухгалтер работает с отчетами или журналами ему необходима информация, которая не связана с тем, как записана операция (сформирована одним из документов или введена вручную). Введение таких общих данных свойственных бухгалтерским операциям во все документы было бы весьма расточительным, так как во многих конфигурациях далеко не все документы записывают проводки.
Другой задачей решаемой операциями является отражение всех документов, относящихся к бухгалтерскому учету в журнале операций. Эта задача тесно связана с предыдущей. Она так же помогает представить бухгалтеру все документы с точки зрения их отношения к бухгалтерскому учету. В журнал операций могут не включаться документы, не имеющие отношения к бухгалтерскому учету. При этом в журнале операций обычно не отражается специфическая информация документов, а отражается только та информация, которая единообразно представляет все документы в механизме бухгалтерского учета. Наличие в метаданных объекта "Операция" позволяет определить в конфигурации не только состав данных свойственных всем операциями, но и способ представления операций в журнале.
- "Запрос" - объект метаданных типа "Запрос";
- Текст запроса - текстовое описание запроса к ИБ на специализированном языке запросов;
- Выборка - набор данных, полученных в результате выполнения запроса;
- Группировка данных - накопление различных значений одного и того же типа данных.
- Отчёт - совокупность текста запроса, процедуры его выполнения и интерпретации выбранных данных.
Для начала, прежде чем проектировать запрос, необходимо задаться вопросом: "Что же я хочу в результате получить?". Да, да, именно так все и начинается, с тривиальной "постановки задачи".
Предположим, я хочу получить "Данные об оборотах и остатках товаров на складах за какой-то период времени" в виде вот такой таблицы:
Уже изначально, в постановке задачи прозвучали все необходимые данные для построения запроса, такие как: обороты, остатки, товары, склады и период времени . Начнем по порядку:
1. "... за какой-то период времени". Значит, мы можем описать период времени, за который запрос будет извлекать информацию. Отразим это:
Период с '98' по '98'
Правды ради, следует отметить, что задание конкретных дат интервала запроса не слишком удобно в большинстве случаев, поэтому создадим в модуле отчета две внешние переменные, определяющие дату начала и конца запроса - ДатаС и ДатаПо :
Период с ДатаС по ДатаПо;
2. "Данные об оборотах и остатках товаров ...". Значит, мы хотим видеть перечень товаров. Ну что ж, давайте так и сделаем - объявим переменную запроса - Товар
Товар =
3. "Данные об оборотах и остатках товаров на складах ...". Для каждого товара хотим отобразить склад, на котором он хранится. Для этого объявляем переменную Склад :
Склад =
4. "Данные об оборотах ". Во-первых, необходимо определиться, какие конкретные обороты мы хотим отразить: денежные, количественные. Давайте определим
Количество =
Поскольку нам нужны данные об оборотах, то следует объявить и сами функции накопления:
Приход = Функция Приход(Количество);
Расход = Функция Расход(Количество);
Данные об оборотах можно получить различными способами – из документов, обходя все или определенные виды документов за конкретный период времени, и из регистров.
5. "Данные об остатках ". Объявим функции остатков:
НачОст = Функция НачОст(Количество);
КонОст = Функция КонОст(Количество);
Данные об остатках из документов уже не получишь, для этой цели предназначены регистры остатков. Следовательно, в работе запроса мы будем использовать регистры. Этот вывод существенно помогает в проектировании запроса, так как мы теперь в состоянии корректно описать переменные, зная, что учет оборотов и остатков ведется по регистру "Товарные запасы":
Товар = Регистр.ТовЗап.Товар;
Склад = Регистр.ТовЗап.Склад;
Количество = Регистр.ОстаткиТоваров.ОстатокТовара;
6. Если мы хотим получить перечень товаров, то нам необходимо эти товары группировать, то есть отображать различные виды товаров. Для чего мы заводим группировку по переменной Товар :
Группировка Товар;
7. Те же самые резоны приводят нас к созданию группировки по переменной Склад :
Группировка Склад;
8. Теперь соберем полный текст запроса, который можно присвоить какой-нибудь переменной модуля отчёта, скажем, ТекстЗапроса:
ТекстЗапроса =
"Период с ДатаС по ДатаПо
|Товар = Регистр.ТовЗап.Товар;
|Количество = Регистр.ТовЗап.ОстатокТовара;
|Приход = Функция Приход(Количество);
|Расход = Функция Расход(Количество);
|НачОст = Функция НачОст(Количество);
|КонОст = Функция КонОст(Количество);
|Группировка Товар;
|Группировка Склад;
|"//}}ЗАПРОС
;
Получившийся текст запроса - это только часть необходимой работы для получения отчёта, но это как раз та часть, которой мы посвятили эту главу методических рекомендаций.
После того, как создан агрегатный объект типа "Запрос":
Запрос = СоздатьОбъект("Запрос");
сформулирован текст запроса и присвоен переменной ТекстЗапроса , запрос запускается на выполнение:
Запрос.Выполнить(ТекстЗапроса);
Что же происходит внутри этого метода? Как же там всё устроено?
Попадая в метод Выполнить , текст запроса превращается в выборку путём следующих метаморфоз:
- проверка синтаксиса;
- создание таблицы выборки;
- накопление данных.
Сначала проверяется правильность написания самого текста запросов - синтаксическая проверка запроса. Может быть пропущен символ ";", может быть неверно указан путь переменной запроса, в любом случае ошибки должны быть обнаружены и исправлены.
Для выявления синтаксических ошибок на стадии разработки (ещё при работе в конфигураторе) воспользуйтесь пунктом меню " Действия – Синтаксический контроль запросов... " , выберите запросы для проверки и нажмите кнопку OK.
Поскольку речь зашла о синтаксисе, обсудим его мало освещенные аспекты.
достаточно подробно описано в книге "Описание встроенного языка. Часть 2". Но хотелось бы ещё раз обратить внимание на то, что описание переменной обуславливает характер обхода ИБ для формирования выборки. Мы можем описать переменную Товар различными способами:
Товар = Справочник.Товар.ТекущийЭлемент;
или
Товар = Документ.РасходнаяНал.Товар;
или
Товар = Регистр.ОстаткиТоваров.Товар;
и во всех трех случаях запрос будет вести себя по-разному. В первом случае запрос пройдет по всем элементам справочника Товар и выдаст полный его перечень. Во втором случае запрос пройдет по документам типа РасходнаяНал и выберет только те товары, которые были проданы по этим документам. А в третьем случае запрос пройдет по движениям или по остаткам регистра (в зависимости от того, какие функции были применены в запросе) и соберет те товары, которые участвовали в этих движениях или присутствовали в остатках.
Если переменную описывают путем с более чем одной ссылкой на объект типа справочник, документ, план счетов и т.д., то говорят, что переменная описана ДЛИННЫМ ПУТЕМ, например
Валюта = Регистр.ОстаткиТоваров.Товар.ВалютаРаботы;
Адрес = Документ.РасходнаяНал.Клиент.Адрес;
Так же хотелось обратить внимание на следующие особенности синтаксиса. При работе с регистрами имеется возможность обращения не только к документу, вызвавшему движение регистра:
Док = Регистр.ИмяРегистра.ТекущийДокумент;
но и к общим реквизитам документов:
Реквизит = Регистр.ИмяРегистра.ТекущийДокумент. ИмяРеквизита;
и к самим полям документов. Но для этого необходимо указать, из каких типов документов необходимо выбирать значения:
Поле = Регистр.ИмяРегистра.ТекущийДокумент. ИмяДокумента.ИмяПоля;
При описании поля документа нельзя не указывать имени самого документа, даже если такое поле встречается в каждом документе конфигурации. Для решения этой проблемы нужно либо объявить поле общим реквизитом документов, либо перечислить в описании переменной все необходимые типы документов:
Поле = Регистр.ИмяРегистра.ТекущийДокумент.
ИмяДокумента1.ИмяПоля,
Регистр.ИмяРегистра.ТекущийДокумент. ИмяДокументаN.ИмяПоля;
Для ИБ в формате .DBF не следует злоупотреблять длинными путями, так как это увеличивает время формирования выборки, ведь запросу приходится считывать не только реквизит указанного документа или регистра, но и по ссылке на объект считывать сам этот объект для извлечения данных. Что нельзя сказать о ИБ в формате SQL. Объект Запрос формирует запрос к SQL серверу, и чем больше работы будет переложено на плечи SQL сервера, тем быстрее будет формироваться выборка.
задает временной интервал выборки данных. Параметрами этого предложения могут быть:
- Дата - в формате встроенного языка '64', '1995'.
Внешняя переменная - глобальная переменная модуля отчёта или идентификатор элемента управления формы отчёта типа Дата или Документ . Если переменная - типа Документ , то интервал запроса устанавливается на дату и время указанного документа.
- Выражение встроенного языка. Задается в круглых или фигурных скобках и может иметь тип, как Дата, так и Документ, например:
Период с (ДатаС + 1) по (ПолучитьДокументТА());.
Задаёт условие включения данных в выборку. Для оптимизации времени выполнения запроса следует знать, что в 1С:Предприятии версии 7.7 запрос сам выполняет, а не вызывает для этого исполнительную среду встроенного языка, условия вида:
ЛеваяЧастьУсловия знакСравнения ПраваяЧастьУсловия
где,
ЛеваяЧастьУсловия и ПраваяЧастьУсловия могут быть константой, переменной запроса или внешней переменной;
знакСравнения - логический оператор (">", "<", "=", "<>", ">=", "<=", "в", "in").
Ниже приведен пример запроса с элементарными условиями:
"//{{Запрос(ЭлементарноеУсловие)
|Период с ДатаС по ДатаПо;
|Товар = Документ.ПриходнаяНал.Товар;
|Дата = Документ.ПриходнаяНал.ДатаДок;
|КолВо = Документ.ПриходнаяНал.Количество;
|Группировка Товар упорядочить по Товар.Наименование;
|Условие(Дата <> ИсключитьДату);
|Условие(Товар = ВыбранныйТовар);
|Условие(КолВо >= 43);
|Условие((Дата <> ИсключитьДату) ИЛИ (КолВо >= 43))
"//}}
;
Следует обратить внимание на то, что отдельные условия в
запросе объединяются по "И", то есть запросы
Условие(ВыходнойДень(Дата) = 0);
Условие(Товар в ВыбранныйТовар);
и
Условие((ВыходнойДень(Дата) = 0) И (Товар в ВыбранныйТовар)
= 1));
будут выполняться одинаково.
Если условие не подходит под определение элементарного, то оно выполняется механизмом внутреннего языка системы 1С:Предприятие.
Если существует возможность разбить сложное условие на элементарные, то так и следует поступить. Допустим, что нам необходимо применить условие вида:
"//{{Запрос(ПреобразованиеУсловия_Было)
|//...
|Условие(Флаг = Перечисление.Булево.Да);
|//...
"//}}
;
, то для оптимизации времени исполнения запроса следует, объявить глобальную переменную:
Перем True;
а в конце модуля определить её как
True = Перечисление.Булево.Да;
и применить эту переменную для формирования элементарного условия:
"//{{Запрос(ПреобразованиеУсловия_Стало)
|//...
|Условие(Флаг = True);
|//...
"//}}
;
Следует обратить особое внимание на то, что оператор принадлежности (в/in), не поддерживается внутренним языком 1С:Предприятия, поэтому оператор принадлежности должен использоваться только в элементарных условиях вычисляемых самим Запросом. И поэтому следующий пример будет выдавать ошибки при выполнении запроса:
"//{{ЗАПРОС(ОшибкаОператораПринадлежности)
|//...
|Условие(Товар.Код в ВыбТовар.Код);
|//...
"//}}
;
в 1С:Предприятии версии 7.5 обогатился следующими реквизитами Все и Все ВошедшиеВЗапрос . Эти реквизиты созданы для того, чтобы давать возможность создавать табличные отчёты, разворачиваемые по горизонтали и вертикали. Для иллюстрации вышесказанного, обратимся к классике - отчёту "Остатки товаров на складах".
Далее приведен текст процедуры программного модуля, реализующего формирование отчёта:
//*******************************************
// Процедура формирования отчета//
Процедура ПоСкладам()
Перем Запрос, ТекстЗапроса, Таблица;
//Создание объекта типа Запрос
Запрос = СоздатьОбъект("Запрос");
ТекстЗапроса =
"//{{ЗАПРОС(ПоСкладам)
|Скл = Регистр.ОстаткиТоваров.Склад;
|Товар = Регистр.ОстаткиТоваров.Товар;
|КолВо = Регистр.ОстаткиТоваров.ОстатокТовара;
|Группировка Товар Упорядочить По Товар.Код;
|Группировка Скл Упорядочить По Скл.Код Все;
|Функция КО = КонОст(КолВо);
|"//}}ЗАПРОС
;
// Если ошибка в запросе, то выход из процедуры
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
Возврат;
КонецЕсли;
// Подготовка к заполнению отчета данными запроса
Таблица=СоздатьОбъект("Таблица");
Таблица.ИсходнаяТаблица("ПоСкладам");
Таблица.ВывестиСекцию("Заголовок");
// Формирование шапки отчета
Таблица.ВывестиСекцию("Шапка|Боковик");
Счётчик = 0;
Пока Запрос.Группировка("Товар") = 1 Цикл
Пока Запрос.Группировка("Скл") = 1 Цикл
Таблица.ПрисоединитьСекцию("Шапка|Склад");
Счётчик = Счётчик + 1;
КонецЦикла;
Если Счётчик>0 Тогда
прервать;
КонецЕсли;
КонецЦикла;
Запрос.ВНачалоВыборки();
// Процесс формирования строки отчета
Пока Запрос.Группировка("Товар") = 1 Цикл
Если Запрос.ЭтоГруппа(1) = 1 Тогда
Таблица.ВывестиСекцию("Группа|Боковик");
Для i = 1 по Счётчик Цикл
КоличествоДляТаблицы = 0;
Таблица.ПрисоединитьСекцию("Группа|Склад");
КонецЦикла;
Иначе
Таблица.ВывестиСекцию("Товар|Боковик");
Пока Запрос.Группировка("Скл") = 1 Цикл
КоличествоДляТаблицы = Запрос.КО;
Таблица.ПрисоединитьСекцию("Товар|Склад");
КонецЦикла;
КонецЕсли;
КонецЦикла;
// Вывод заполненной формы отчета
Таблица.ТолькоПросмотр(1);
Таблица.Опции(0,0,5,0);
Таблица.Показать("Остатки товаров на складах","");
КонецПроцедуры
Выходная таблица отчёта имеет следующий вид:
Остатки товаров на складах
Следует упомянуть тот факт, что "Запрос" дает возможность доступа к переменным, группировкам и функциям по их именам. Значения упорядочивания хоть и находятся в выборке, но у их нет имени и следовательно, доступ к их значениям по имени невозможен. Для доступа к их значениям применяется метод ЗначениеУпорядочивания. Использование этого метода, может существенно ускорить время обхода выборки, по сравнению с использованием конструкций типа:
Запрос.ИмяГруппировки.ИмяПоля
из-за того, что значение ИмяПоля, система будет повторно выбирать из ИБ.
В 1С:Предприятии версии 7.7 появились новоые возможности по упорядочиванию группировок. Первая, это возможность упорядочивать значение группировки по функции. вторая, возможность новый реквизит предложения Группировка – без упорядочивания . Реквизит без упорядочивания удобен для пакетного режима выполнения запроса, когда не важно расположение элементов группировки, а необходимы только результаты. В этом случае сбор данных упорядочивания отключается полностью, в том числе и по умолчанию, что положительно сказывается на производительности.
В этом разделе хочется обратить внимание на то, что значения функций, объявленных в запросе, определены, накапливаются и сворачиваются по всем уровням группировок, начиная с самой старшей группировки - "Итого" и кончая самой младшей. Как иллюстрацию, приведем следующий пример:
Процедура ОстаткиТоваров()
Перем Запрос, ТекстЗапроса, Таб;
//Создание объекта типа Запрос
Запрос = СоздатьОбъект("Запрос");
ТекстЗапроса =
"//{{ЗАПРОС(ОстаткиТоваров)
|Период с ДатаС по ДатаПо;
|Товар = Регистр.ОстаткиТоваров.Товар;
|Склад = Регистр.ОстаткиТоваров.Склад;
|КолВо = Регистр.ОстаткиТоваров.ОстатокТовара;
|Группировка Товар упорядочить по
| Товар.Наименование;
|Группировка Склад упорядочить по
| Склад.Наименование;
|Функция Количество = КонОст(КолВо);
|"//}}ЗАПРОС
;
// Если ошибка в запросе, то выход из процедуры
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
Возврат;
КонецЕсли;
// Подготовка к заполнению выходных форм данными
Таб = СоздатьОбъект("Таблица");
Таб.ИсходнаяТаблица("ОстаткиТоваров");
// Заполнение полей "Заголовок"
Таб.ВывестиСекцию("Заголовок");
Состояние("Заполнение выходной таблицы...");
Пока Запрос.Группировка("Товар") = 1 Цикл
// Заполнение полей Товар
Таб.ВывестиСекцию("Товар");
Пока Запрос.Группировка("Склад") = 1 Цикл
// Заполнение полей Склад
Таб.ВывестиСекцию("Склад");
КонецЦикла;
КонецЦикла;
// Заполнение полей "Итого"
Таб.ВывестиСекцию("Итого");
// Вывод заполненной формы
Таб.Опции(1, 0, 1, 0);
Таб.Показать("ОстаткиТоваров", "");
КонецПроцедуры
В результирующей таблице мы видим, что значение функции определено для Результирующей записи - "Итого", для группы справочника Товары, для элемента справочника Товары, для элемента справочника Склад. То есть, значение функции определено на всех уровнях вложенности.
Запрос создает временные файлы для накопления и хранения выборки на компьютере, с которого этот запрос запустили. Формат хранения временных файлов .DBF - .CDX.
Структура записи таблицы выборки следующая:
- Поля группировок . Поля группировок идут последовательно в порядке их объявления в тексте запроса, и этот порядок крайне важен. Поле группировки состоит из полей упорядочивания и поля значения. По полям упорядочивания и полям значения строятся индексы, и следует иметь в виду, что максимальная длина ключа .CDX .файла равна 240 байтам. Если вы заводите большое количество группировок или большое число полей упорядочивания – достичь этой величины не составляет труда. При превышении максимально допустимого значения механизм запросов пропорционально уменьшает длину строковых полей упорядочивания, входящих в ключ. Если же длина ключа превышает 240 байт, а возможность сократить её за счёт строковых полей отсутствует, то обработка запроса прекратится с ошибкой "Длина индекса превышает максимальную длину и не может быть уменьшена".
- Поля функций накопления . Это самые обыкновенные числовые поля с максимальной длиной. Эти поля не входят в индексы.
- Поля внутренних переменных запроса , по которым не велись ни группировки, ни накопление. Такие переменные нужны для выборки данных из объектов группировки, по которым не нужно вести ни группировку, ни упорядочивание, а значение необходимо.
После того, как мы узнали, что представляет собой запись таблицы выборки, мы наконец-то можем поговорить о том, как накапливаются данные, подчёркиваю, именно,накапливаются . Как говорилось выше, обход ИБ запросом зависит от определения путей переменных. Если переменная Товар в тексте запроса определена следующим образом:
Период с ДатаС по ДатаПо;
Товар = Документ.РасходнаяНал.Товар,
Документ.РасходнаяКредит.Товар;
Склад = Документ.РасходнаяНал.Склад,
Документ.РасходнаяКредит. Склад;
КолВо = Документ.РасходнаяНал.Количество,
Документ.РасходнаяКредит. Количество
Группировка Товар;
Группировка Склад;
Сумма = Функция Сумма(КолВо);
то запрос сначала обойдет все документы вида РасходнаяНал за указанный период, а затем - все документы вида РасходнаяКредит . И каждый раз запрос будет формировать запись, заполняя поля группировок, функций и внутренних переменных. После формирования записи, запрос будет добавлять её в таблицу выборки. Если полученного сочетания значений группировок нет, запрос добавляет запись в таблицу выборки:
а если такое сочетание значений группировок существует, то запись накапливается :
Если в записи не заполнено какое-либо поле группировок, то запись не считается сформированной, не записывается и не участвует в накоплении значений.
Использование граф отбора может существенно убыстрить время формирования запроса, но для того, чтобы воспользоваться графами отбора, запрос должен удовлетворять следующим требованиям:
- в запросе должна быть объявлена переменная, пути которой включены в графу отбора;
- должно быть задано элементарное условие;
- условие должно быть со знаком сравнение "=".
Товар = Регистр.ИмяРегистра.Поле;
Условие(Товар = ВыбТовар); // (+)
Условие(Товар <> ВыбТовар); // (-) не знак =
Условие((Товар) = ВыбТовар); // (-) не элементарное
// условие
где ВыбТовар - внешняя переменная запроса.
У объекта метаданных типа "Запрос" существует метод ИспользоватьГрафуОтбора , который может управлять механизмом выборки данных с использованием графы отбора.
Параметр метода ИспользоватьГрафуОтбора может принимать следующие значения:
"*" - автоматический выбор графы отбора. Если в тексте запроса описаны элементарные условия со знаком "равно", то запрос просматривает переменную, фигурирующую в условии, и пытается найти для неё соответствующую графу отбора, и, если такая переменная найдена, то включается механизм выборки данных с использованием графы отбора. Когда в тексте запроса объявлены несколько условий, удовлетворяющих критериям включения механизма выборки данных с использованием графы отбора, перед запросом встает задача выбора одной единственной графы отбора из списка возможных. Запрос в своих оценках выбора графы отбора ориентируется на количество элементов справочников и перечислений. Для других типов оценка не производится, и, при желании, можно задать графу отбора вручную.
имя графы отбора . Графа отбора задаётся вручную. Если она задана неверно, то тогда при выполнении запроса выведется сообщение: "Нет переменной, удовлетворяющей заданной графе отбора".
" " - отказ от использования графы отбора.
Метод Выполнить может быть применен к объекту "Запрос" неограниченное количество раз. Приведем тому пример:
Процедура Сформировать()
Перем Запрос, ТекстЗапроса, Таб;
Запрос = СозадтьОбъект("Запрос");
ТекстЗапроса =
"//{{ЗАПРОС(ТекстЗапроса1)
|...
"//}}ЗАПРОС
;
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
Возврат;
КонецЕсли;
// Цикл обработки запроса
...
"//{{ЗАПРОС(ТекстЗапроса2)
|...
"//}}ЗАПРОС
;
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
Возврат;
КонецЕсли;
// Цикл обработки запроса
КонецПроцедуры
При повторном вызове метода Выполнить , объект Запрос инициализирует внутренние структуры, и доступ к переменным, объявленным в предыдущем запросе и выбранным данным становится, не возможен.
Особенности позиционирования >. После формирования выборки, запрос позиционируется на первую запись ("Итого") – в начало выборки, с которой начинается обход выбранных значений. Вернуться в начало выборки, можно двумя способами. В цикле обхода пройти всю выборку до конца;
// Формирование шапки отчета
Таблица.ВывестиСекцию("Шапка|Боковик");
Счётчик = 0;
Пока Запрос.Группировка("Товар") = 1 Цикл
Если Счётчик = 0 Тогда
Пока Запрос.Группировка("Скл") = 1 Цикл
Таблица.ПрисоединитьСекцию("Шапка|Склад");
Счётчик = Счётчик + 1;
КонецЦикла;
КонецЕсли;
КонецЦикла;
// Процесс формирования строки отчета
Пока Запрос.Группировка("Товар") = 1 Цикл
Если Запрос.ЭтоГруппа(1) = 1 Тогда
Таблица.ВывестиСекцию("Группа|Боковик");
Для i = 1 по Счётчик Цикл
КоличествоДляТаблицы = 0;
Таблица.ПрисоединитьСекцию("Группа|Склад");
КонецЦикла;
Иначе
Таблица.ВывестиСекцию("Товар|Боковик");
Пока Запрос.Группировка("Скл") = 1 Цикл
КоличествоДляТаблицы = Запрос.КО;
Таблица.ПрисоединитьСекцию("Товар|Склад");
КонецЦикла;
КонецЕсли;
КонецЦикла;
или воспользоваться методом "Запроса" - ВначалоВыборки:
Таблица.ВывестиСекцию("Шапка|Боковик");
Счётчик = 0;
Пока Запрос.Группировка("Товар") = 1 Цикл
Пока Запрос.Группировка("Скл") = 1 Цикл
Таблица.ПрисоединитьСекцию("Шапка|Склад");
Счётчик = Счётчик + 1;
КонецЦикла;
Если Счётчик > 0 Тогда
прервать;
КонецЕсли;
КонецЦикла;
Запрос.ВНачалоВыборки();
// Процесс формирования строки отчета
Пока Запрос.Группировка("Товар") = 1 Цикл
Если Запрос.ЭтоГруппа(1) = 1 Тогда
Таблица.ВывестиСекцию("Группа|Боковик");
Для i = 1 по Счётчик Цикл
КоличествоДляТаблицы = 0;
Таблица.ПрисоединитьСекцию("Группа|Склад");
КонецЦикла;
Иначе
Таблица.ВывестиСекцию("Товар|Боковик");
Пока Запрос.Группировка("Скл") = 1 Цикл
КоличествоДляТаблицы = Запрос.КО;
Таблица.ПрисоединитьСекцию("Товар|Склад");
КонецЦикла;
КонецЕсли;
КонецЦикла;
Метод ВначалоВыборки можно вызывать на любом уровне вложенности циклов обработки выборки, для перехода в ее начало. Количество обходов выборки ничем не ограничено.
Примером неправильной работы с данными в 1С:Предприятиии, есть и остается избыточное обращение к базе данных, вне зависимости от того, в каком формате она хранится.
Как избежать лишних обращений к ИБ, и тем самым существенно уменьшить время формирования отчета проиллюстрируем на примере "Оптимизация Отчета".
Закладка 100%
ТекстЗапроса =
"//{{ЗАПРОС(Сформировать100)
|Период с ВыбНачПериода по ВыбКонПериода;
|Товар = Документ.РасхНакл.Товар;
|Количество = Документ.РасхНакл.Количество;
|Функция КоличествоСумма = Сумма(Количество);
|Группировка Товар;
|Условие(Товар в ВыбТовар);
|Условие(Товар.ВидТовара = ВыбВидТовара);
|"//}}ЗАПРОС
;
При написании текста запроса необходимо учитывать, что Запрос при формировании выборки сам отрабатывает только элементарные условия , не запуская при этом исполнительную среду встроенного языка, что значительно экономит время. Если есть возможность привести условие к элементарному - это необходимо сделать.
"//{{ЗАПРОС(Сформировать15)
|Период с ВыбНачПериода по ВыбКонПериода;
|Товар = Документ.РасхНакл.Товар;
|ВидТовара = Документ.РасхНакл.Товар.ВидТовара;
|Количество = Документ.РасхНакл.Количество;
|Функция КоличествоСумма = Сумма(Количество);
|Группировка Товар;
|Условие(Товар в ВыбТовар);
|Условие(ВидТовара=ВыбВидТовара);
|"//}}ЗАПРОС
;
Так как выборка формируется на компьютере пользователя, то все данные, которые необходимы пользователю для построения отчета, должны быть, по возможности, получены посредством запроса. В таблице выводится значение кода товара – для этого в запросе необходимо ввести переменную КодТовара . Тогда для формирования отчета, отпадет необходимость, каждый раз обращаться к ИБ. Следует не забывать про методы Запроса - ЗначениеУпорядочивания и ЭтоГруппа , которые опять же извлекают данные из выборки, минуя ИБ, что заметно уменьшает время формирования запроса.
"//{{ЗАПРОС(Сформировать3)
|Период с ВыбНачПериода по ВыбКонПериода;
|Товар = Документ.РасхНакл.Товар;
|ВидТовара = Документ.РасхНакл.Товар.ВидТовара;
|КодТовара = Документ.РасхНакл.Товар.Код;
|Количество = Документ.РасхНакл.Количество;
|Функция КоличествоСумма = Сумма(Количество);
|Группировка Товар;
|Условие(Товар в ВыбТовар);
|Условие(ВидТовара=ВыбВидТовара);
|"//}}ЗАПРОС
;
В отчете "Оптимизация Отчета" время выполнение самой медленной версии взято за 100%, остальные версии берутся как процент от нее. Следование правилам, дало возможность уменьшить время выполнения запроса почти на 2 порядка!
В случае применения объекта "Запрос" для выборки информации из справочников 1С:Предприятия необходимо учитывать следующую особенность. При обработке справочника объект "Запрос" не обрабатывает группы справочника. То есть он не использует их в качестве исходных данных для получения первичной выборки. При обработке уже полученных записей запрос добавляет группы для выбранных записей - элементов, если существует группировка по переменной запроса типа "Справочник". Такой способ обработки является стандартным, и Запрос выполняет ее так же, как он это делает, например, для реквизитов документа имеющих тип "Справочник". То есть, если в запросе по документам использовать группировку по реквизиту "Товар" документа "Счет", то в полученном отчете можно получить записи и по группам товаров, вошедших в запрос. Аналогично, если в запросе по справочнику получать в качестве группировки текущий элемент, то в полученный отчет будут включены записи, соответствующие группам отобранных запросом элементов. Однако так как сами группы не обрабатываются запросом при заполнении таблицы выборки, то в отчет не попадут те группы, которые не имеют элементов, или группы, элементы которых не попали в выборку. Соответственно объект "Запрос" не может применяться в тех случаях, когда нужно обрабатывать собственно группы, или получать все элементы, включая группы. С другой стороны, так как в большинстве случаев должны выбираться непосредственно элементы, запрос может быть успешно применен для обработки справочника. В том числе, Запрос позволяет существенно ускорить выборку элементов по условию, при работе с базой данных в формате SQL.
При обработке с помощью запроса справочников, имеющих периодические реквизиты,
следует учитывать, что значения периодических реквизитов выбираются только
на конечную границу периода запроса. То есть, с помощью запроса нет возможности
получить историю периодических реквизитов, а можно получить только срез значений
на определенный момент.
