Так принято в ERP, что практически очень сложно что-то удалить навсегда. Можно создать бухгалтерский документ или карточку основного средства, а вот удалить их система не дает: бухгалтерский документ можно только сторнировать, а карточку основного средства можно только списать.
По разным обстоятельствам очень редко возникает необходимость в зачистке оперативных продуктивных данных. Такая необходимость может быть регулярной (так называемая Архивация) или иррегулярной (например: удаление тестовых данных при подготовке к продуктивному старту).
Для полной очистки оперативных данных (по БЕ) предусмотрены специальные программы в модулях финансовой бухгалтерии FI (транзакция OBR1) и основных средств AM (транзакция OABL). Эти программы действуют очень грубо и без оглядки на остальные модули, и к тому же не могут заменить саму функциональность Архивации. Но вот в остальных модулях (например: MM, FM) такой возможности нет. Единственный легальный способ удалить оперативные данные в прочих модулях или удалить их на основании утверждённых сроков жизни – это Архивация.
Архивация – это процесс выборочного переноса записей из оперативной базы данных во внешние файлы.
В реальной жизни архивация нужна для систем с долгим сроком продуктивной жизни. Для каждого вида документов есть свой период актуальности, и если система ERP работает уже лет пять, то разумно предположить, что конкретные документы пятилетней давности нам уже не нужны для работы. Конечно же, мы должны сохранить некоторые общие промежуточные итоги того периода в самой системе, например сальдо счетов. А если кроме этого у вас необходимые данные в том или ином виде выгружаются в систему класса BI – то тем лучше.
Конечно это выгодно также и технологически – разгружается сама база данных, уменьшается размер резервных копий, повышается быстродействие. Кроме этого доступ к архиву в каком-то ограниченном виде возможен, а также не исключается возможность восстановить данные из файлов обратно в базу данных.
Ну а мы будем сейчас использовать архивацию для избавления от мусора.
Чисто теоретически можно было бы написать программы по прямому удалению из таблиц, но это не наш метод.
Эта статья покажет процесс архивации на примере модуля управления материальными запасами (MM).
Приступим!
Шаг первый: Списание остатков
Требуется списать все остатки на всех складах.
В моём случае это выполняется при помощи самописной Z-программы.
Схема программы простая:
1. Определить открытый период на заводе. Тут всё просто: таблица MARV
2. Определить свободный запас. Тут чуть сложнее: таблица MCHB (для материалов с учётом по партиям) и MARD (для материалов без учёта по партиям).
3. Списать весь свободный запас. Ну и есть функциональный модуль BAPI_GOODSMVT_CREATE
Требуется немного программирования; красивая, безопасная и удобная обёртка не помешает.
Шаг второй: Настройка длительности жизненного цикла к нужным объектам
Из транзакции SARA можно перейти к конкретным пунктам настройки для каждого объекта:
В этом меню нам может иногда пригодиться третий пункт (там настраиваются тестовые и продуктивные варианты).
Основное здесь – это настройка сроков жизни в последнем пункте этого меню.
Кроме всего прочего здесь можно посмотреть, какие именно физические таблицы используются для каждого архивируемого объекта.
Знание таблиц не помешает для контроля, да и в качестве общих сведений тоже полезно.
Эти настройки можно также найти разрознено в SPRO или общим списком напрямую, воспользовавшись уличной магией (смотри V_159R, V_169R и прочие ракурсы):
Здесь не без вариаций, таблички не совсем однотипные. Настройка для материальных документов (MB01/MIGO) выгляди так:
Решёточки – означают все виды операций (именно в данном случае).
Настройка для фактур уже немного другая:
А значение жизненного цикла равное нулю означает именно нулевой срок жизни объекта, а не бесконечный срок жизни (как некоторым может показаться с первого раза).
Не перечисленные в настройке ОрганизационныеЕдиницы и ВидыОпераций/ВидыОбъектов не будут архивироваться (бесконечный срок жизни).
Делаем настройки, переносим – ничего сверхординарного.
Шаг третий: Зачистка материальных документов
Здесь вступает в дело основная транзакция процесса архивации – SARA. Это центральная транзакция архивирования.
Начинаем идти по принципу “снизу-вверх”, сначала вычищаем материальные документы – объект MM_MATBEL.
К этому объекту надо будет выполнить две первых операции.
Сначала запускаем операцию “Запись” – для формирования внешних файлов.
Создаём варианты. Их понадобится как минимум два: один тестовый и один продуктивный.
В первый раз, безусловно, запускаем тестовый прогон. Внимательно смотрим результат:
Можно пройти по табличкам, убедиться в правдоподобности цифр.
И после этого операцию следует повторить в продуктивном режиме.
Семь раз отмерили? Переходим к этапу “Удаление”.
Удалить можно только то, что прочитали. Выбираем архив – и понеслась! Только сначала в тестовом режиме,а затем – в продуктивном.
Остаётся только посмотреть по таблицам в SE16 и убедиться лично (на всякий пожарный, для успокоения).
Шаги четвёртый и последующие
Затем процесс повторяется для прочих объектов, имеющих отношение к модулю MM. Здесь не обойдётся без отклонений от основного сценария.
Условная последовательность выметания (на основе однократного опыта):
- Документы материалов (MM_MATBEL)
- Документы счетов (MM_REBEL)
- Заказы на поставку (MM_EKKO)
- Контракты (MM_EKKO)
- Партии и прочая история (MM_INVBEL, MM_HDEL, LO_CHVW)
- Материалы (MM_MATNR)
Но в результате обнаружения всяческих засад мере я выметал в несколько проходов.
Мелкие засады
Без мелких засад тут может и не обойдётся. Например, временно сохранённые документы фактур не попадают в архивацию, а можно ли их удалить из интерфейса при удалённом заказе — вопрос. Незавершённые заказы на поставку могут сильно сопротивляться попыткам их заархивировать (особенно если там ПМ/ПС не ровно), а выровнять ПМ/ПС (например: ошибка двойного фактурирования) не есть простая задача при удалённых документах.
Кроме SARA могут пригодиться программы RM06EW30 (альтернативная прямая архивация) и RWPOB001 (закрытие заказов на поставку). Кроме этого, не стоит забывать о возможностях массовой обработки заказов на поставку (MEMASSPO) и контрактов (MEMASSCONTRACT).
А как же MMDE? Удаляет материалы без архивирования.
Ну во-первых, эта транзакция удаляет все материалы. А иногда надо выборочно, например только на некоторых заводах.
Ну а во-вторых, эта транзакция не удаляет всё остальное — контракты, заказы, фактуры, документы.
Добрый день,
Иван,
Помогите пожалуйста, может быть Вы подскажите мне. Поступила задача удалить дубликат BP (чистый, без движений) в системе. Вариант через BUPA_DEL, неприемлем в связи с выпуском ноты (2599676 — Transaction BUPA_DEL is obsolete).
Изучая процесс «Архивации и удаления», столкнулся с проблемой настройки объекта CA_BUPA в тр. SARA. Смоделировал ситуацию: создал нового чистого BP. Установил метки «Для архивации»: «можно удалить» и «архивация возможна». То есть в BP, на вкладке «Статус», стоит метка архивации. Ок с этим.
Дальше, настроил объект CA_BUPA в тр. AOBJ (прога записи: BUSOBARCH, прога удаления: BUSOBARCH_DELETE, галочки сняты все).
Дальше, тр. SARA, об. CA_BUPA, записываю в архив. Создал вариант с продуктивным исполнением для проги BUSOBARCH. Сохранил. Запланировал задание, спул ок.
Проверяю задание: получаю «Невозможно заархивировать BP» (error: CMS_IF_FSBP, 006).
Пытался тоже самое сделать без «метки архивации» в BUPA_DEL — такая же ошибка.
Стесняюсь попросить, можете Вы в песочнице проверить настроки AOBJ и SARA для CA_BUPA.
В базе знаний, перерыл весь launchpad.support.sap.com. Не нашел ничего :(
Удалил дубликатов BP, а также их роли (дебитора, кредитора). Через тр. SARA (как того предписывает SAP (snote 2599676)) у меня удалить не получилось. Задание программы архивации планируется и выполняется с помощью фонового задания. Отследить ошибку (error: CMS_IF_FSBP, 006) дебагом в программе записи BUSOBARCH — не получилось. Было принято решение (несмотря на ноту 2599676) удалять тр. BUPA_DEL и OBR2. Сначала сняли все метки (удаления, блокировки) с кредиторов/дебиторов — этого требует OBR2 (снять метки в тр. XK05, XK06, XD05, XD06). Потом проверил все таблицы, чтобы не было критических переменных данных (LFC1, BSEG, KNA1,LFA1,LFB1, KNB1). Запускаю удаление «Общих данных» с «данными по БЕ» кредитора/дебитора в тр. OBR2. Удалил кредиторов/дебиторов. Запускаю тр. BUPA_DEL — удаляю BP (для BUPA_DEL без разницы стоят либо не стоят метки удаления/архивации в BP). В тр. BUPA_DEL сначала столкнулись с такой же ошибкой CMS* 006, однако ошибка ушла с созданием нового FM ZFS_CMS_BPDP_DELE1_CHECK, вместо стандартного FS_CMS_BPDP_DELE1_CHECK. FM создан копированием, он идентичен стандартному. Далее новый FM добавили в тр. BUS7 для события DELE1, новой позицией 4600001 и поставили X на вызов. Соот-но для стандартного FM FS_CMS_BPDP_DELE1_CHECK, убрали вызов и оставили с той же позицией 4600000. После этого запустил BUPA_DEL и удалил BP без ошибки. Для архивации и удаления — используйте тр. SARA, ибо BUPA_DEL не поддерживается SAPом с июля 2018 года. Всю ответственность по сопровождению BUPA_DEL они с себя сняли, поэтому в случае неконсистентности данных в базе — эти проблемы будете решать вы сами. И еще нюанс тр. BUPA_DEL: ради эксперимента попробовал удалить BP с ролями кредитора/дебитора и с проводками в BSEG. Он удалился через BUPA_DEL, только сначала сбросил переменные по БЕ в тр. OBR1, а затем в тр. OBR2 удалил мастер данные дебитора/кредитора. OBR2 удалил прицепом все его документы в BSEG начисто! При просмотре в FB03 — ошибка «Документ №… не существует в финансовом году 2019».