Интеллектуальное восстановление последовательности в 1С

Каждую ИТ систему по ведению учета на предприятии можно разделить на две условные категории с точки зрения хронологической коррекции данных.

Материал предоставлен компанией "СофтПоинт"/

Каждую ИТ систему по ведению учета на предприятии можно разделить на две условные категории с точки зрения хронологической коррекции данных:

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

2) Допускаются изменения задним числом. Корректность данных по цепочке измененных документов достигается регламентной процедурой перепроведения документов.
Подобная система является противоположностью вышеописанной системы. Соответственно это касается всех преимуществ и недостатков. Одним из недостатков является обязательное наличие регламентной процедуры коррекции цепочки измененных документов. В случае существенного роста информационного потока процедура перепроведения может продолжаться длительный промежуток времени. В случае когда эта процедура станет отнимать более 12-и часов это процедура становится потенциально опасной в надежности функционировании всей ИТ системы. Данную процедуру в типовой реализации необходимо выполнять в вечернее время так как она отнимает много серверных ресурсов и реализует много блокировок что негативно сказывается на общей работе пользователей.

Система 1С Предприятие 7.7. как правило, реализует вторую схему. Регламентная процедура коррекции измененных документов называется восстановлением последовательности 1С. Основными недостатками при изменении задним числом будут следующие пункты:

1) При изменении задним числом возникает относительно большой временной интервал между самим изменением и восстановлением последовательности в 1С.

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

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

Документы БД (усреднённая статистика):
Приходная накладная: 10 документов в день по 500 строк.
Расходная накладная: 100 документов в день по 100 строк.
Приходный кассовый ордер: 100 документов в день (без табличной части).
Расходнный кассовый ордер: 100 документов в день (без табличной части).
Регистры учета:
ОстатокТовараПоПартиям(Товар,Партия,Количество)
ОстатокТовара(Товар,Склад,Количество)
Взаиморасчеты(Клиент,Документ,Сумма)

Прибыль пускай рассчитывается по FIFO и взаиморасчеты тоже. Вообще нужно отметить, что это типовая реализация схемы расчета для конфигураций 1С предприятие 7.7. В этом случае, в отличие от линейной записи в регистр, при изменении задним числом изменяется вся партионная очередь измерения. Что бы ее восстановить необходимо пересчитать все связанные не только партия-образующие(приход) документы но партия-зависящие(расход).

Что произойдет, если мы поменяем данные по одной строчке товара приходной накладной 10-и дневной давности?

Что бы рассчитать количество связанных документов необходимо учитывать структуру регистров, по которым ведется расчет. Соответственно для того, что бы восстановить последовательность необходимо пересчитать все документы, которые участвуют в движении по регистрам измененного товара за 10-ть дней. Однако, как правило, мы не знаем в типовой реализации какую именно позицию мы меняли и поэтому пересчитываются все документы за данный период. Учитывая, что измененная строка в приходной накладной могла повлиять на взаиморасчеты нам приходится пересчитывать и ПКО и РКО. Итого получается необходимо даже после одной измененной строки провести порядка Кол.Документов=(10+100+100+100)=310 документов и соответственно обработать (500*10+100*100+100*1+100*1) = 15200 строк! Вдумайтесь еще раз в эти цифры! Даже одна измененная строка задним числом предполагает такую ресурсоемкую обработку.

В чем же причины такого неэффективного механизма восстановления последовательности в 1С?

Первая это – потеря истории изменения. Вследствие чего невозможно сказать каким было состояние документа до изменения. Это исключает селективное, выборочное перепроведение документов.

Вторая и немаловажная – отсутствие возможности обработки движений регистров построчно. Даже если будет возможно сказать какая именно позиция была изменена в документе то нельзя будет обрабатывать только эту позицию в модуле обработки проведения. Это уже следствие частично неэффективной реализации платформы 1С Предприятие 7.7.
Итогом такой реализации стало то, что при изменении одной позиции в документе все равно придется препроводить весь документ. Изменив одну строку в документе приходной накладной нам в программной реализации придется обработать остальные 499-т строк, которые не менялись!

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

Краткое описание технической реализации:

Включение логирования на T-SQL, следствием которого является ведение надежного лога по изменению в регистрах движения.
В дальнейшем специальной обработкой можно будет получать связанные последовательностью документы. Для восстановления последовательности нам необходимо будет перепроводить только их. Обработку написать эту довольно не сложно – фактически это запрос по регистрам с отбором по измерениям которые были изменены. Можно обойтись и без логирования, но это менее надежно и более трудоемко (например запоминая состояние до записи документа и после а потом записывать эту информацию в отдельный справочник).

Преимущества: Относительная простота реализации, отсутствие правки в модуле конфигурации.
Недостатки: Не максимальная селективность в отдельных случаях. Практически нельзя вести оперативный пересчет связанных документов в он-лайн. По прежнему высокие затраты производительности при проведении связанных документов.

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

Это комплексное решение позволяет максимально снизить количество перепроводимых документов и связанных в них строк. В данном случае независимо от специфики базы будет обрабатываться только та информация, которая была завязана на изменение. Пересчет, возможно, будет выполнять в он-лайн так как он не будет отнимать много производительных ресурсов. Также время пересчета уменьшится на несколько порядков.
Соответственно между изменением задним числом и восстановлением последовательности будет проходить как правило(зависит от специфики базы) менее минуты. Также уменьшится время перепроведения документа – будет обрабатываться только измененная информация.

Краткое описание технической реализации:

Включение логирования на T-SQL, следствием которого является ведение надежного лога по изменения в регистрах движения. Реализуются специальные процедуры позволяющие очищать выборочно движения по регистрам. Отдельно производится анализ конфигурации и изменения в ней соответствующие концепции выборочной обработки движений по регистрам учета.
С помощью технологии внешних компонент можно реализовать процедуру которая будет аналогом процедуры ОчиститьДвижения(<ВидыДвижений>) 1С – только будет более расширенной.
А именно : ОчиститьДвиженияПоИзмерениям(<ВидыДвижений>,Измерения,СписокЗначений) - Эта процедура будет очищать не все движения по документу тем самым пересчитывая ненужную информацию и расстанавливая дополнительные блокировки а выборочно по списку значений. Как правило, это будет разница между табличной частью проведенного документа до изменения и после.
Соответственно если в табличной части были изменены 3-и позиции из 100, то удалятся только 3-и позиции. Естественно процедура будет удалять не только движения по документу, но и производить агрегационный пересчет остатков по периодам хранения. Однако это, к сожалению не все и править конфигурацию все равно придется.
Рассмотрим, какие именно изменения нужно будет произвести что бы эти изменения работали корректно. В первую очередь это анализ остатков. Тут необходимо понимать, что в проведении документа большинство времени уходит не на удаление записей, а именно на расчет остатков. Если мы знаем что остатки по 97-и позициям из вышеприведенного примера не изменились, то рассчитывать их имеет смысл только по 3-м измененным позициям. Соответственно необходимо произвести тщательный анализ конфигурации и выполнить соответствующие изменения.

Если ЗначениеВходитВСписокИзмененных(СпИзм,Значение)=0 Тогда Продолжить; КонецЕсли; Также аналогичные изменения необходимо провести и в местах модуля, где происходит запись в регистр. Движения по регистрам должны осуществляться только по измененным позициям.

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

Преимущества: Максимальная селективность в процедуре восстановления последовательности. Обрабатывается только связанная информация. Минимальное время между изменением и восстановлением последовательности. В случае не массовых изменений задним числом время восстановления будет ускоренно более 100-и раз.(вообще то разница зависит от объема изменения). Минимальная нагрузка при перепроведениии.
Недостатки: Относительная сложность внедрения. Необходимо изменять модуль конфигурации. При добавлении новых объектов необходимо учитывать специфику реализации.

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

Компания "СофтПоинт" представляет готовое решение, которое позволит снять проблему восстановления последовательности.

Начать дискуссию