Типичные проблемы при закрытии бухгалтерского периода в 1С 7.7 и варианты их решений

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

Соответственно, после правки всех ошибок следует перепроведение необходимых регламентных документов, таких, например, как "Закрытие месяца". Чем больше организация, тем большее количество людей задействовано в этом процессе. Десятки бухгалтеров могут одновременно корректировать документы, перепроводить их, запускать различные регламентные отчеты и обработки.

В результате получается нелинейный рост нагрузки следующего характера:

Значительно увеличивается интенсивность работы пользователей в базе по вводу/изменению данных.
Значительно увеличивается интенсивность работы пользователей по построению различного рода отчетности.
В результате роста интенсивности ввода данных происходит рост количества и увеличение средней длительности блокировок данных, массово появляются ошибки с сообщениями о невозможности проведения документа.
Происходит снижение КПД работы всех сотрудников бухгалтерского отдела, вынужденных ожидать реакции информационной системы на свои действия (замедляется ввод документов, построение отчетов).
Увеличиваются затраты рабочего времени, увеличивается длительность рабочего дня, сотрудники вынуждены оставаться на работе надолго после окончания рабочего дня с целью завершить все работы к сроку.

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

Проблема блокировок тоже стоит особенно остро. Если учесть тот факт, что документы в обычном режиме работы 1С:предприятие 7.7 проводятся строго последовательно один за другим, то попытка провести много документов одновременно у многих пользователей приведет только к большому количеству сообщений о невозможности провести документ, простоям пользователей, невозможности завершить все действия к определенному сроку.

Решение проблемы должно быть комплексным, а именно:

Необходимо кардинально решить проблему блокировок – обеспечить параллельный ввод и обработку данных с минимальным количеством блокировок при этом, обеспечить целостность данных, но при этом избежать проблем "грязного чтения".
Повысить эффективность выборки (чтения) данных из базы, путем оптимизации алгоритмов бухгалтерских запросов, оптимизации типичных узких мест конфигурации и платформы, иначе полученный эффект от отсутствия блокировок будет съеден возросшим уровнем нагрузки на сервер в результате параллельной работы пользователей. Альтернатива – достаточно мощный сервер с большим запасом производительности, рассчитанный на работу в режиме пиковой нагрузки.
Сделать работу системы гибко настраиваемой, с возможностью работать как в полноценном многопользовательском режиме, так и в монопольном, при этом без необходимости вручную заново конфигурировать или настраивать систему.
Кроме всего прочего – требуется настроить SQL-сервер на режим максимальной производительности при пиковых нагрузках.

Результатом внедрения такого решения должно стать нормальное функционирование системы в режимах пиковых нагрузок – при сдаче квартальной отчетности, годовой, отчетности по налогам и т.д.

Наилучшим образом таким требованиям удовлетворяет комплекс "Гибкие Блокировки".

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

Таким образом, получается, что два документа, при условии их проведения по одному и тому же счету бухгалтерского учета будут пытаться изменить одну запись, при этом второй документ будет ожидать окончания транзакции проведения первого документа, а значит, параллельного проведения документов не получается.
Выход из данной ситуации был найден и реализован следующим образом: для каждой из двух таблиц бухгалтерских итогов создается дополнительная пара таблиц, которые объединяются путем общего представления по этим таблицам. При этом одна из таблиц является основной копией, другая содержит только вносимые изменения. Причем изменения вносятся только командой INSERT, т.е. в таблицу осуществляется только вставка данных, а не обновление. В результате блокировки нет. Два документа, при условии проведения по одному счету оба делают вставку в таблицу вместо обновления, и не ждут друг друга.

Отрицательный эффект при этом в том, что таблица изменений начинает довольно интенсивно увеличиваться в объеме (в зависимости от интенсивности работы). Чтобы выйти из данной ситуации создается периодическая задача (JOB), которая копирует данные из таблицы изменений в главную таблицу. Получается система типа «накопитель»: с одной стороны поступает большое количество данных, с другой стороны – более ранние данные сворачиваются, группируются и копируются в главную таблицу с удалением из таблицы изменений. Таблица изменений растет за счет работы большого количества пользователей, которые проводят или перепроводят документы, и уменьшается за счет регулярной перекачки данных. Таким образом, достигается баланс: достижение минимального уровня блокировок и оптимального уровня быстродействия системы.

Еще один этап – повышение эффективности обработки данных с целью после внедрения комплекса "Гибкие Блокировки" избежать ситуации, когда эффект внедрения был нивелирован возросшей нагрузкой на сервер (в отсутствии возможности расширения аппаратной части). В связи с особенностями хранения и обращения к данным в компоненты "Бухгалтерский учет", есть целый ряд возможностей по оптимизации. Как правило, стандартная бухгалтерская конфигурация имеет в плане счетов 3 субконто. Для доработанных конфигураций их может быть 4 или 5. Одна из особенностей платформы заключается в том, что с ростом максимального количества субконто в плане счетов построение отчетов типа "оборотно-сальдовая ведомость" и производных от него значительно замедляется. Все из-за того, что запрос к данным используется в одной типовой форме, без учета специфика плана счетов, поэтому его эффективность ниже, чем могла бы быть. Более подробно описано в статье "Оптимизация скорости бухгалтерских запросов в 1с с помощью компоненты "SPDesigner".

Если кратко, то в вышеуказанной статье расписывается проблема и предлагается алгоритм, который позволяет увеличить скорость выполнения запросов оборотно-сальдового типа с фильтрами по счетам и субконто. Описываемый там алгоритм требовал вмешательства в код конфигурации.

В комплексе «Гибкие Блокировки» реализован усовершенствованный автоматический алгоритм, который делает все то же самое, но без необходимости вмешательства в конфигурацию. Т.е. сама компонента умеет определять все настройки и самостоятельно оптимизировать все передаваемые на выполнение бухгалтерские запросы. В результате происходит автоматическая оптимизация производительности без вмешательства программиста или пользователя. Эффект от оптимизации значительный, в первую очередь сокращается количество логических чтений из базы данных, а также уменьшается затрачиваемое на построение запроса процессорное время.

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

При внедрении комплекса "Гибкие Блокировки" обязательно происходит анализ настроек SQL-сервера, и сервер настраивается на режим максимальной пиковой производительности.

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