KoderLine
KoderLine
Обслуживание и внедрение
программного обеспечения
Киев

Статьи экспертов

Полезная информация

Опыт свертки базы 1С:Підприємство

0
256
16.05.2020 Константин Новичков

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

Как выполнить очистку информационной базы 1С:Підприємство, при этом сохранив всю важную информацию?

В этом случае на помощь придет «свертка информационной базы 1С:Підприємство» - процесс обработки документации и регистров конфигурации, благодаря которым удаляется старая, ненужная документация. На ее месте создается несколько документов ввода остатков на указанный период. Следовательно, выполняется «обрезка» ведения учета до указанного периода.

Главными целями свертки являются:

·        ускорение работы системы;

·        сокращение размера информационной базы.

Рассматривать вариант свертки стоит в следующих случаях:

·        «торможение» 1С:Підприємство;

·        большие объемы базы 1С:Підприємство (минимум 5 ГБ и более);

·        длительное обновление программы;

·        «мешает» документация прошлых лет.

В процессе работы появилась задача свертки базы 1С:Підприємство при переходе с ERP 2.0 на ERP 2.1?

На момент потребности свертки компания создала штатные механизмы лишь для УТ 11 и БП 3.0, и для более старых версий.

Для выполнения свертки в качестве основы берутся механизмы из УТ 11. Релиз УТ 11 был взят примерно того же времени выпуска, что и ERP 2.0.

Свертка выполняется в три этапа:

·        внесение остатков;

·        удаление информации за прошлые временные промежутки (удаление движений и пометка на удаление документации);

·        сверка остатков с функционирующей базой.

Чтобы внести остатки в любой версии имеется специальная документация.

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

Фрагменты документации занесения остатков в УТ 11 подразумевает процесс автоматического внесения остатков по регистрам.

Например, «товары на складах», «взаиморасчеты с клиентами/поставщиками», «заказы клиента/поставщику», «возвратная тара», «денежные средства».

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

К примеру, «расчеты с сотрудниками», частично по регистрам бухгалтерии, кадровому учету, Внеоборотные активы.

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

·        Заполнение документов «Ввод начальных остатков»

Каждый вид операции добавления остатков был проанализирован на наличие механизма ввода остатков в обработке из УТ 11, были определены, какие регистры двигают данный вид операции. Для несуществующих механизмов ввода остатков были созданы собственные.

·        Заполнение документов «Корректировка регистров», «Перенос данных» и «Операция (регламентированный учет)»

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

К примеру, остатков на производственных регистрах, «прочие активы и пассивы», «заказы на перемещение», «распоряжение на выпуск», «расчеты с фондами по страховым взносам».

Возможна доработка конфигурации для добавления остатков по следующим регистрам (механизмам) либо создание добавления остатков при помощи документации:

 

 

·        Сложные схемы ввода остатков

Некоторые механизмы ERP не могут быть ограничены добавлением остатков на дату свертки. Это связано с тем, что для определенных механизмов ключевая информация располагается не только в регистрах, но и в самой документации. В основном это документация, на которую ссылаются данные регистров. В традиционной обработке добавления остатков данный механизм создан для учета заказов покупателя. Его принцип заключается в следующем:

 


 

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

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

Удаление информации выполняется в несколько этапов:

·        удаление движений документации

·        пометка документации на удаление

При удалении движений по каждому регистру:

1.      Отмечается вся документация, которая:

- «двигала» регистр до даты свертки

- не содержит специальных комментариев, оставленных на прошлых этапах

2.      Отключается использование итогов

3.      Для каждой документации удаляются движения

Под каждый вид документации создается список, в котором отсутствует специальный комментарий. И он отмечается пометкой на удаление.

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

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

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

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

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

Есть несколько вариантов решения данной проблемы:

1.      В рабочей базе привести остатки по регистрам накопления в порядок

2.      Переписать процедуры добавления остатков с данных регистров накопления на данные регистров бухгалтерии (если данные в регистрах бухгалтерии покрывают данные в регистрах накопления).

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

И все казалось бы просто, если бы не большое время выполнения обработки – от нескольких часов до нескольких недель.

Продолжительность процесса свертки зависит от:

·        конфигурации базы

·        применяемых подсистем

·        объема добавленных данных до даты свертки

Из-за длительного процесса появляется несколько серьезных проблем:

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

2.      Сложности тестирования обработки свертки. На этапе создания методологии свертки либо создания кода обработки увеличивается цена ошибки. К примеру, если процесс свертки занимает 1 день, то процесс тестирования при 10 ошибках может затянуться на 10 дней, если каждая ошибка не будет выявлена сразу, а она будет появляться только каждого нового тестирования. А если для свертки потребуется не один день, а несколько? А если в программе не 10 ошибок, а намного больше?

Для решения данных проблем применялся план обмена и обработки «Выгрузка и загрузка данных XML».

В рабочей базе был добавлен план обмена, который фиксировал все изменения после создания копии базы для свертки. После свертки измененные данные в рабочей базе переносились обработкой «Выгрузка и загрузка данных XML». Следовательно, пользователям не нужно было добавлять информацию в Новую базу, она была занесена туда автоматически.

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

При обнаружении новых ошибок – вышеперечисленные операции должны быть повторены. Этот метод существенно ускорил процесс разработки и тестирования процедур добавления остатков.

Советы из личного опыта по свертки базы ERP

База клиента состояла из 1.5 млн. документации в прошлом периоде.

Продолжительность операций составляла:

1 час – добавление остатков

6 суток – удаление движений

4 суток – установка пометок удаления

В связи с тем, что процесс разработки достаточно сложный, а длительность осуществления этапов свертки велика, то была определена следующая последовательность работ:

1.      Добавление в рабочей базе плана обмена.

2.      Копирование базы – «новая свернутая база».

3.      Запуск в свернутой базе процессов удаления всей информации до даты свертки (наиболее длительная по времени процедура).

4.      Анализ остатков и разработка операций добавления остатков.

5.      Создание в отдельной копии процедуры добавления остатков (с фиксацией изменений в плане обмена).

6.      Перенос информации добавления остатков из копии рабочей в «новую свернутую базу».

7.      Проверка остатков, если необходимо, то повторное выполнение пунктов 5, 6, 7.

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