|
|
Для орагнизации свертки информационной базы обычно создается отдельная ее копия и в ней запускается обработка, которая выполняет операции, описанные выше. Копия базы делается для того чтобы сохранить в отдельной базе старые данные, а в новой свернутой базе продолжить работу.
Все было бы просто, если бы не большое время выполнения обработки – от нескольких часов до нескольких недель.
Длительность процесса свертки зависит от:
Из-за длительности процесса возникают две существенные проблемы:
1. Двойная нагрузка на пользователей. Пока не будет готова новая свернутая база, необходимо продолжать учет: выписывать документы, расчитывать и фиксировать измененные данные, сдавать отчетность. После создания новой свернутой базы пользователям необходимо в новой базе внести всю информацию, которая вносилась в старую во время процесса свертки и параллельно вносить новые данные, т.е. выполнять текущую работу . Кроме того еще надо сверить в новой остатки и проверить работу системы после внесения остатков, т.к. могут быть скрытые ошибки свертки базы.
2. Сложность тестирования обработки свертки. На этапе разработки методологии свертки или написания кода обработки возрастает цена ошибки. Если, например, процесс свертки занимает 1 день, то процесс тестирования при 10 ошибках может занять 10 дней, если каждая ошибка выявлялась не сразу, а после каждого нового тестирования. А если свертка занимает не 1 день, а неделю? А если не 10 ошибок, а больше?...
Для решения этих проблем я использовал план обмена и обработку “Выгрузка и загрузка данных XML”.
В рабочей базе я добавил план обмена, фиксирующий все изменения после создания копии базы для свертки. После свертки измененные данные в рабочей базе переносил обработкой “Выгрузка и загрузка данных XML”. Таким образом пользователям не пришлось вносить данные в Новую базу, они были перенесены автоматически.
Выявление ошибок написания кода обычно происходит на этапе сверки остатков, т.е. после введения остатков и удаления данных прошлых периодов. Так как этап удаления довольно длительный, а правильность введения остатков в большинстве случаев не зависит от этапа удаления, то практичнее тестирование и доработку ввода остатков делать в отдельной третьей базе. Пока в Новой базе проходил процесс удаления данных прошлых периодов, я устранял выявленные ошибки в обработке свертки и дорабатывал новые процедуры свертки. После окончания удаления старых документов и движений у меня была готова Новая база, но с неправильными остатками. На отдельной копии рабочей базы я формировал документы остатков, изменения автоматически фиксировались в плане обмена, и обработкой “Выгрузка и загрузка данных XML” переносил измененные остатки в Новую рабочую базу. При выявлении новых ошибок – повторял эти операции. Данный метод значительно ускорил разработку и тестирование процедур ввода остатков.
|
|
|
|
База клиента содержала 1,5 млн. документов в прошлом периоде.
Длительность операций составляла:
1 час – ввод остатков
6 суток – удаление движений
4 суток – установка пометок удаления
Так как процесс разработки довольно трудоемкий, а продолжительность выполнения этапов свертки велика, то на будущее я определил для себя следующую последовательность действий:
1. Добавление в рабочей базе плана обмена.
2. Создание копии базы – «новая свернутая база»
3. Запуск в свернутой базе процедуры удаления всех данных до даты свертки (самая длительная операция)
4. Анализ остатков и разработка операций ввода остатков
5. Формирование в отдельной копии процедуры ввода остатков (с регистрацией изменений в плане обмена)
6. Перенос данных ввода остатков из копии рабочей в «новую свернутую базу»
7. Проверка остатков, при необходимости повторение пунктов 5,6,7.
Сложно с первого, да и со второго раза написать идеальную обработку свертки базы для 1С:ERP, необходимо досконально знать изнутри каждый механизм, каждую подсистему, но с каждым разом будет получаться все лучше и лучше
|
|
