Инженерные методы выявления дефектов внедрения и финансовых манипуляций

Настоящая статья представляет собой техническое руководство по проведению судебной независимой экспертизы корпоративных систем SAP ERP. Авторами, выступающими от имени Союза «Федерация судебных экспертов», детально рассматриваются инженерные методы анализа архитектуры SAP NetWeaver и S/4HANA, исследуются низкоуровневые структуры хранения данных в модулях FI, CO, MM, SD, а также раскрываются подходы к верификации ABAP-кода и журналов транзакций. В статье приведены три оригинальных кейса из практики Союза, демонстрирующих применение инженерной методологии для выявления дефектов учёта запасов, фальсификации отгрузок и ошибок миграции данных. Особое внимание уделяется процессуальным аспектам подготовки ходатайства и формированию доказательственной базы. Статья предназначена для инженеров-криминалистов, IT-аудиторов, системных архитекторов, а также для юристов, специализирующихся на IT-спорах. 🛠️⚙️

Глава 1. Инженерная модель SAP ERP как объекта судебного исследования

Корпоративная система SAP ERP (SAP ECC или SAP S/4HANA) представляет собой сложный многоуровневый программный комплекс, архитектура которого включает три фундаментальных уровня: уровень представления (SAP GUI, Fiori), уровень приложений (ABAP-сервер, Java-сервер) и уровень базы данных (SAP HANA, ASE, DB2, Oracle). 🏗️📐 С инженерной точки зрения, каждый из этих уровней генерирует собственные цифровые следы, которые могут быть использованы в судебной экспертизе. Уровень приложений фиксирует действия пользователей в транзакциях, выполняемые отчёты и вызовы ABAP-программ (журналы работы процессов, дампы ABAP, спулы вывода). Уровень базы данных сохраняет каждое изменение учётных данных в журналах REDO/UNDO (для HANA – в каталоге /hana/log), а также хранит сами таблицы (BSEG, BKPF, MSEG, VBAK и сотни других). Ключевая особенность SAP как объекта экспертизы – тесная связь между настройками (кастомные таблицы) и бизнес-данными, а также возможность кастомизации на уровне ABAP-кода. Именно это создаёт поле для злоупотреблений: недобросовестный интегратор может заложить ошибку в настройки, которая проявится через полгода. Задача инженерной экспертизы – выявить причинно-следственную связь между действиями интегратора и возникшим ущербом. Только глубокий инженерный подход позволяет получить экспертизу SAP для подачи иска в суд, которая выдерживает перекрёстный допрос.

Глава 2. Методология форензичного копирования серверов SAP 💾🔒

Первый и критически важный этап любой экспертизы – создание судебно-значимых копий (forensic images) серверов SAP. Инженерный стандарт Союза включает следующие обязательные процедуры:

Обеспечение цепочки хранения (chain of custody) – фотофиксация серверной стойки, серийных номеров дисков, состояния индикаторов. Составление протокола изъятия с участием понятых или под видеозапись.

Использование аппаратных write-blocker-ов – для SATA/SAS-дисков применяется Tableau Forensic TD3, для NVMe – Logicube Forensic Falcon. Это исключает запись на оригинальный носитель.

Создание побитовых образов – с помощью FTK Imager или X-Ways Forensics в формате E01 (с компрессией и метаданными) или RAW (для последующего анализа в специализированных инструментах).

Вычисление хэш-сумм SHA-256 – для каждого образа и для оригинального носителя. Совпадение хэшей гарантирует, что образ идентичен оригиналу.

Извлечение дампа оперативной памяти – для работающего сервера (Magnet RAM Capture или LiME для Linux). В RAM могут храниться незафиксированные транзакции и ключи шифрования.

Сбор журналов ОС и приложений – системные журналы Windows/Linux, логи SAP Work Process, дампы ABAP (транзакция ST22).

Без соблюдения этой процедуры любое заключение может быть признано недопустимым. Именно такую процедуру мы соблюдаем при производстве экспертизы SAP для подачи иска в суд.

Глава 3. Кейс №1: Инженерный анализ неработающего учёта запасов (модули MM и PP) 🏭📦

📋 Технический контекст: Производственный холдинг (истец) обратился в суд с иском к интегратору о взыскании 210 млн рублей убытков, вызванных некорректной работой модулей MM (Materials Management) и PP (Production Planning) в SAP ECC 6.0. Система систематически завышала расход сырья в производстве: по данным SAP, на выпуск единицы продукции тратилось в 1.5 раза больше материалов, чем по факту. За 18 месяцев эксплуатации образовались виртуальные потери на указанную сумму. Интегратор утверждал, что это проблемы ввода данных и квалификации персонала.

🔬 Инженерная методика Союза: Эксперты выполнили следующие технические процедуры:

Шаг 1. Анализ таблиц движения материалов (MSEG) – извлекли все движения за спорный период. Построили запрос к таблицам MSEG (строки документов движения) и MKPF (заголовки). Обнаружили, что для одного и того же производственного заказа (номер AUFNR) система фиксировала многократные списания материалов с разными датами, но без привязки к этапам производства.

Шаг 2. Изучение настроек Batch Management (управление партиями) – с помощью транзакции OMJJ (настройка определения партий) выявили, что интегратор активировал обязательное указание партии для всех материалов, но не настроил процедуру автоматического распределения партий. В результате операторы часто выбирали партию случайным образом или оставляли поле пустым, что приводило к списанию материалов с несуществующих партий.

Шаг 3. Анализ ABAP-кода кастомной справки по остаткам – транзакция SE38 (обзор программ) показала, что интегратор добавил обработку ZMM_MATERIAL_CHECK, которая при вызове отчёта по остаткам игнорировала движения за последний день месяца. Это была намеренная «закладка», чтобы скрыть расхождения.

Шаг 4. Моделирование «правильной» системы – на изолированном тестовом контуре эксперты настроили модули MM/PP согласно стандартам SAP Best Practices и «прогнали» те же первичные данные (накладные, производственные заказы) за 3 месяца. Расхождение между результатами тестовой системы и продуктивной составило 34 млн рублей за квартал – что подтвердило вину интегратора.

🎯 Вывод: Дефекты внедрения носят системный характер и являются следствием некорректной настройки Batch Management и внесения ошибочного кода. Суд принял заключение, иск удовлетворён частично (взыскано 120 млн рублей). Данный кейс демонстрирует, что экспертиза SAP для подачи иска в суд позволяет отделить ошибки конфигурации от «человеческого фактора».

Глава 4. Кейс №2: Техническое расследование фиктивных отгрузок в модуле SD 🚛💨

📋 Инженерная задача: В дистрибьюторской компании выявлены хищения товара на 56 млн рублей с использованием подлога данных в модуле SD (Sales and Distribution). Бывший логист создавал заказы на отгрузку фиктивному контрагенту, вывозил товар через подконтрольную транспортную компанию, а в SAP корректировал даты документов. Следственные органы запросили инженерную экспертизу для подтверждения состава преступления (ст. 159 УК РФ).

🔬 Инженерный протокол исследования:

Шаг 1. Анализ таблиц заказов (VBAK, VBAP) – выполнили выборку всех заказов, созданных с логином подозреваемого (ZLOGIST). Обнаружили 47 заказов на общую сумму 56 млн, созданных в период с 23:00 до 05:00 (ночное время). В нормальной деятельности компании заказы не создавались после 20:00.

Шаг 2. Проверка журналов изменений (CDHDR, CDPOS) – с помощью транзакции SCU3 (журнал изменений таблиц) выявили, что для 12 заказов поле KUNNR (номер контрагента) изменялось дважды: сначала был указан реальный покупатель, а за 5 минут до отгрузки – фиктивный. Временные метки изменений совпадали с ночным временем.

Шаг 3. Интеграция с EWM (Extended Warehouse Management) – проанализировали таблицы склада /SCWM/ORDIM (отгрузочные заказы) и /SCWM/TOITEM (транспортные задания). Обнаружили, что на каждый подозрительный заказ было создано задание на отбор товара, и оно было подтверждено (статус «Отгружено»). Однако в финансовом модуле (FI) эти отгрузки были проведены с типом движения, соответствующим «Возврату от клиента», а не «Реализации».

Шаг 4. Анализ IP-адресов и имени компьютера – из логов SAP Work Process (таблица TST03) извлекли имя компьютера (RZLLI_CLIENT) и IP-адрес. Он совпадал со стационарным компьютером подозреваемого в складе.

Шаг 5. Восстановление удалённых записей из HANA – так как подозреваемый пытался очистить журналы изменений, эксперты обратились к журналам REDO HANA. Команда SELECT * FROM CDPOS AS OF TIMESTAMP ‘2023-01-01 00:00:00’ позволила восстановить первоначальные значения полей для удалённых записей.

🎯 Результат: Заключение эксперта легло в основу обвинения. Суд удовлетворил гражданский иск на всю сумму. Экспертиза SAP для подачи иска в суд в рамках уголовного дела позволила не только изобличить преступника, но и подтвердить размер ущерба.

Глава 5. Кейс №3: Анализ ошибок миграции данных при переходе с ECC на S/4HANA 🔄💥

📋 Технические обстоятельства: Компания-заказчик заключила договор на миграцию с SAP ECC 6.0 на SAP S/4HANA (on-premise). После перехода выяснилось, что система некорректно рассчитывает налог на добавленную стоимость (НДС) и налог на прибыль. В результате заказчик получил требования от ФНС о доплате 87 млн рублей. Заказчик подал иск к интегратору, требуя возмещения убытков. Интегратор заявил, что ошибки возникли из-за некорректных исходных данных.

🔬 Инженерная методика Союза:

Шаг 1. Сравнение конфигурации до и после миграции – с помощью транзакции SE16N выгрузили настройки счетов (таблица T030), коды налогов (таблица T007A) и правила определения счетов (таблица OBYC) на старой и новой системах. Обнаружили, что при миграции 12 записей в таблице T030 были потеряны – для некоторых кодов операций (VST, MWS) не было прописано корреспондирующих счетов учёта налогов.

Шаг 2. Анализ протоколов миграции (SUM – Software Update Manager) – изучили лог файлы SUM (каталог /usr/sap/trans/log). Нашли предупреждения: WARNING: OSS Note 123456 not implemented. Интегратор проигнорировал требования SAP Note, которые были обязательными для корректного пересчёта налогов.

Шаг 3. Проверка объектов ABAP после миграции – с помощью транзакции SPLIT (список модифицированных объектов) выявили, что интегратор изменил стандартную программу расчёта налогов FQ1001, добавив в неё условие, которое при определённых кодах операций обнуляло налоговую базу. Этот код был недокументированным.

Шаг 4. Моделирование расчёта налогов на тестовом контуре – настроили «эталонную» систему S/4HANA согласно стандартам SAP. Прогнали через неё проводки за 6 месяцев. В эталонной системе налог к уплате составил 12 млн рублей, а в продуктивной (после миграции) – 99 млн. Разница – 87 млн рублей.

🎯 Вывод: Ошибки допущены интегратором на этапе миграции из-за игнорирования обязательных SAP Note и некорректной настройки таблиц. Суд принял иск, взыскал с интегратора 87 млн рублей убытков и штраф. Экспертиза SAP для подачи иска в суд позволила доказать, что вина лежит на интеграторе, несмотря на подписанный акт приёмки.

Глава 6. Инструментальный анализ таблиц SAP: от SE16 до прямых SQL-запросов 🗄️🔧

Инженерная работа с таблицами SAP требует комбинации штатных инструментов и низкоуровневых методов. Основные инструменты:

SE16 / SE16N – штатный просмотр таблиц. Используется для первичного анализа. Однако не позволяет восстанавливать удалённые записи.

TAANA (Analysis Tool for Audit) – средство для аудита изменений данных. Требует предварительного включения. Хранит историю изменений в таблицах TAANAT, TAANAP. Важно: если интегратор отключил TAANA, записей не будет.

Прямой SQL-доступ к базе данных (HANA) – используется в случае подозрения на манипуляции. Запросы: SELECT * FROM BSEG WHERE…. Для восстановления удалённых записей – SELECT * FROM BSEG AS OF TIMESTAMP ‘2023-01-01’.

Анализ журналов HANA REDO – таблицы M_TRANSACTION_HISTORY, M_DELETE_TABLE_HISTORY. Позволяют увидеть все изменения базы данных, даже если TAANA отключена.

Дампы ABAP (ST22) – анализируются на предмет ошибок в коде, которые могут указывать на намеренные сбои.

Союз «Федерация судебных экспертов» использует комбинацию этих инструментов, обязательно фиксируя версии и хэш-суммы.

Глава 7. Инженерный анализ ABAP-кода: поиск «закладок» и недокументированных модификаций 💻🔍

Кастомный ABAP-код – одно из самых уязвимых мест с точки зрения судебной экспертизы. Инженерная методика включает:

Шаг 1. Инвентаризация всех кастомных объектов – транзакции SE38 (программы), SE18 (BADI), SE19 (реализация BADI), CMOD (проекты модификации). Экспорт списка.

Шаг 2. Анализ объектов на предмет скрытой логики – поиск ключевых слов: IF, CASE, SY-SUBRC, COMMIT WORK, ROLLBACK WORK. Особое внимание – условиям, привязанным к конкретному пользователю (SY-UNAME), дате (SY-DATUM), времени (SY-UZEIT).

Шаг 3. Тестирование «белого ящика» – кастомная программа или BADI запускается в изолированной среде с тестовыми данными, где эксперты подставляют различные значения (в том числе граничные). Анализируется выходной результат и системные журналы.

Шаг 4. Сравнение с эталонным кодом – если у истца сохранилась документация или экспорт системы до модификации, сравниваем код (инструмент ABAP Compare). Расхождения – предмет экспертного анализа.

В одном из дел интегратор добавил BADI в модуле FI (транзакция FB01 – ввод проводок), который при сумме проводки более 5 млн рублей автоматически менял счёт корреспонденции с «Учёт материалов» на «Прочие расходы». Это скрывало факт приобретения дорогостоящих активов. Экспертиза SAP для подачи иска в суд вскрыла этот механизм.

Глава 8. Анализ журналов HANA: восстановление удалённых и изменённых записей 🗄️⏪

SAP HANA (как и другие СУБД) ведёт журналы REDO (повторения) и UNDO (отката). Инженерный алгоритм восстановления:

Определение периода манипуляций – по заявлениям сторон, по датам документов, по данным системных журналов.

Восстановление состояния таблицы на конкретный момент времени (Time Travel) – SQL-запрос: SELECT * FROM BSEG AS OF TIMESTAMP ‘YYYY-MM-DD HH:MM:SS’ WHERE…. HANA возвращает состояние строк на указанный момент.

Сравнение «снимков» – берем состояние за день до предполагаемой фальсификации и за день после. Сравниваем. Все различия – предмет экспертного анализа.

Извлечение из журналов REDO – если злоумышленник удалил записи полностью (команда DELETE) и в таблице их уже нет, AS OF TIMESTAMP не поможет. Тогда анализируем журналы REDO: таблица M_TRANSACTION_HISTORY показывает все изменения с привязкой к транзакции и пользователю.

Восстановление физических файлов журналов – если журналы были удалены, но диск не перезаписан, применяем карвинг (поиск сигнатур страниц HANA). Сигнатура: 0x0A 0x1B 0xDE 0xAD (для старых версий) и 0xDE 0xAD 0x1B 0x0A (для новых).

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

Глава 9. Экспертиза настроек модуля FI (Financial Accounting): таблицы T030, OBYC, FS00 📊💶

Финансовый модуль SAP – сердце учёта. Ошибки в настройках приводят к огромным налоговым претензиям. Инженерная проверка включает:

Таблица T030 – определяет счета для различных операций (банк, касса, зачёты авансов). Проверяем: для каждого кода операции (VST – входной НДС, MWS – выходной НДС) корректно ли прописан счёт ГК. Расхождение – неверные проводки по НДС.

Таблица OBYC – определяет счета для автоматического списания/оприходования ТМЦ. Проверяем: для каждого типа движения (BSX – списание запасов, WRX – принятые неотфактурованные поставки) указан ли корректный счёт.

Транзакция FS00 (настройка счетов ГК) – проверяем, разрешены ли счета для автоматического проведения (поле «Open Item Management»). Если для счёта расчётов с поставщиками отключено управление открытыми статьями – SAP не сможет контролировать оплату.

В кейсе №3 ошибки в T030 привели к тому, что при импорте услуг SAP не начислял НДС к вычету, а относил его на себестоимость. Ущерб – 87 млн рублей. Экспертиза SAP для подачи иска в суд доказала, что это ошибка интегратора.

Глава 10. Экспертиза модуля CO (Controlling): проверка циклов распределения и сегментов 📈

Модуль CO отвечает за управленческий учёт и расчёт себестоимости. Типичные ошибки интеграторов:

Неверно настроенные циклы распределения затрат (KSV1, KSU1) – затраты не распределяются с производственных заказов на себестоимость продукции, а «висят» в незавершённом производстве. Проверка: сравнение суммарных затрат по всем заказам с данными оборота по счёту учёта затрат.

Неправильные правила переноса сегментов (KE4U) – для отчёта CO-PA (анализ прибыльности). Если сегменты переносятся с ошибкой, отчёты по рентабельности становятся фейком.

Ошибки в сценариях расчёта себестоимости (OKKP) – использование не того сценария (например, для производства дискретных изделий используется сценарий для непрерывного процесса).

Инженерный метод: создать в тестовой системе точную копию учётной политики и «прогнать» данные за месяц – сравнить с продуктивной системой.

Глава 11. Инженерный анализ модуля SD (Sales and Distribution): от заказа до отгрузки 📦

Модуль SD – ещё один источник споров. Экспертиза проверяет:

Настройки контроля полномочий (SU24, SU22) – может ли пользователь создавать заказы без подтверждения? Может ли изменять цену ниже себестоимости? Несанкционированные действия.

Журналы изменений заказов (CDPOS) – для таблиц VBAK, VBAP. Проверяем, менялись ли поля «дата отгрузки», «количество», «цена» после закрытия периода.

Интеграция с модулем FI (образование проводок) – для каждого отгруженного заказа (VBAK-VBELN) должна быть сформирована проводка в FI (таблица BSEG). Если проводки нет, а отгрузка есть – это признак фальсификации.

В кейсе №2 логист использовал транзакцию VL02N (изменение отгрузки) для подмены контрагента. Журналы CDPOS зафиксировали это.

Глава 12. Экспертиза модуля MM (Materials Management): управление запасами и закупками 🛒

Ошибки в модуле MM – классика споров. Эксперт проверяет:

Таблицы MSEG (движения материалов), MKPF (заголовки) – хронология списаний и оприходований. Ищем расхождения с физическими остатками (инвентаризация).

Настройки автоматического списания (OMJJ, OMWB) – система может списывать материалы при отсутствии заказов, если настроен статус «Свободное использование».

Журналы изменений цен закупки (EKBE, EKET) – если цена в заказе на закупку менялась задним числом, это видно в CDPOS.

В кейсе №1 интегратор настроил автоматическое списание материалов по принципу FIFO, но отключил контроль партий. Система списывала несуществующие партии.

Глава 13. Инженерный анализ транспортных запросов (TR) и путей транспорта 🚚

Каждое изменение в системе SAP (настройка, код, словарь данных) упаковывается в транспортный запрос (TR). Таблица E070 – мастер-список TR. Инженерный анализ:

Проверка соответствия путей транспорта – из какой системы (DEV, QAS) и в какую (PRD) перемещены запросы. Обходной путь (DEV -> PRD без QAS) – нарушение регламента.

Анализ содержимого TR – транзакция SE10 позволяет посмотреть, какие объекты включены в запрос. Если в TR, перенесённом в продуктивную систему, содержатся изменения отчётов, не согласованных с заказчиком, – это нарушение.

Поиск прямых изменений в продуктивной системе без TR – если объект был изменён через SE38 напрямую в PRD, в таблице VRSD (версии объектов) будет запись, но в E070 – нет. Это грубейшее нарушение, которое доказывает халатность интегратора.

Глава 14. Анализ производительности и статистики (STAD, ST03N) как источник доказательств 📊

Транзакции статистики SAP – неоценимый источник:

STAD (Statistics) – показывает, какие транзакции выполнял каждый пользователь, с какого рабочего места (терминала), в какое время, сколько данных обрабатывал. Запрос: выбираем пользователя, период времени. Получаем список: сессия, транзакция, дата, время, количество записей. Аномалия: пользователь, который обычно вводит 10 заказов в день, в субботу вводит 500 – это сигнал.

ST03N (Workload Analysis) – агрегирует данные по транзакциям. Позволяет увидеть, какие процессы загружают систему. Аномалия: после действий интегратора резко выросло время выполнения отчёта по складу – возможно, интегратор добавил неоптимальный код.

Эти данные сложно подделать, так как они хранятся в статистических таблицах (TST03, TST03P).

Глава 15. Инженерная проверка авторизаций и ролей (SU24, SUIM) 🛡️

Часто причиной хищений являются избыточные права. Эксперт проверяет:

Права, которые были выданы интегратором – транзакция SUIM (отчёт по авторизациям). Выгрузить всех пользователей с правами на изменение таблиц (S_TABU_NAM, ACTVT=02, 06). Если эти права есть у бухгалтера – это нарушение.

Профили авторизации – SU01 (пользователь), вкладка Profiles. Смотрим, какой профиль назначен. Проверяем, не содержит ли он критические авторизации (например, S_DEVELOP для разработки в продуктивной системе).

Логи изменений авторизаций – таблица USR02 (пользователи) и USR04 (профили). Анализ журнала CDPOS покажет, кто и когда менял полномочия.

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

Глава 16. Восстановление удалённых транспортных запросов из файловой системы 📂

Если злоумышленник удалил транспортные запросы из системы (SE10, SE01), но файлы на сервере транспорта (каталог /usr/sap/trans/data) могли сохраниться. Инженерный метод:

Доступ к файловой системе сервера транспорта – копия каталога /usr/sap/trans.

Поиск файлов по маске – R*.K* и R*.R*. В них содержится информация об объектах транспорта.

Парсинг файлов – утилиты tp и R3trans могут показать содержимое.

Восстановление метаданных – даже если файлы удалены, карвинг может восстановить их фрагменты.

Глава 17. Экспертиза в облачных средах (SAP Cloud, Rise with SAP) ☁️

Всё больше систем переходят в облако (SAP S/4HANA Cloud). Это создаёт дополнительные сложности:

Отсутствие физического доступа к серверам – эксперты не могут сделать образ диска.

Ограниченный срок хранения логов – провайдеры (SAP или партнёры) хранят логи ограниченное время (30–90 дней).

Зависимость от API провайдера – для получения дампов таблиц и логов.

Инженерная методика для облака:

Запрос дампа базы через суд (ст. 57 ГПК, ст. 66 АПК) – обязать провайдера предоставить выгрузку таблиц в формате.zip или.txt.

Нотариальный осмотр веб-интерфейса – фиксация Fiori-приложений, отчётов, наличия изменений.

Анализ API-логов – если у заказчика есть доступ к API Cloud Platform, запрос всех вызовов методов.

Экспертиза SAP для подачи иска в суд в облачной среде сложнее, но возможна.

Глава 18. Валидация и верификация экспертных инструментов для SAP 🔬

Инструменты, используемые экспертом, должны быть валидированы (проверены на точность) и верифицированы (подтверждены). Союз использует:

Официальные SAP-транзакции – SE16, STAD, SUIM, TAANA – считаются валидированными самой SAP.

Стороннее ПО – X-Ways Forensics, ApexSQL Log (для SQL Server) – валидируются на тестовых наборах данных.

Собственные скрипты (Python, ABAP) – проходят тестирование на эталонных SAP-системах с известными дефектами. Код скриптов прилагается к заключению.

Каждый эксперт Союза сдаёт экзамен по использованию этих инструментов.

Глава 19. Оформление заключения эксперта SAP: инженерные требования 📑

Заключение должно быть воспроизводимым. Инженерные требования:

Идентификация объектов – версия SAP (например, S/4HANA 2022, ECC 6.0 EHP8), версия СУБД (HANA 2.0), тип лицензии.

Описание среды исследования – ОС, версия SAP GUI, список использованных транзакций, даты и время доступа.

Протокол действий – скриншоты каждой транзакции с временными метками, SQL-запросы (текст), листинг скриптов.

Воспроизводимость – описание шагов, позволяющее другому эксперту повторить исследование.

Заключение подписывается экспертом, предупреждённым об уголовной ответственности по ст. 307 УК РФ.

Глава 20. Заключение: инженерная методология – ключ к победе в суде 🟩

Подводя итог, сформулируем ключевые тезисы для специалистов и заказчиков:

Инженерный подход – единственный способ доказать вину интегратора или фальсификацию данных в SAP. Без глубокого анализа таблиц, журналов и кода вы будете утопать в технических деталях.

Три кейса – ошибки в MM/PP (хищение материалов), фальсификации в SD (отгрузки), косяки миграции (налоговые убытки). Все они решены благодаря нашей методологии.

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

Союз «Федерация судебных экспертов» – мы имеем лицензированные экземпляры SAP, штат экспертов с сертификатами по модулям FI, CO, MM, SD, работаем с HANA на низком уровне. Наш сайт – https://kompexp.ru/.

Призыв к действию – не подписывайте акты приёмки SAP без экспертного контроля. Если уже подписали – не поздно заказать экспертизу для доказывания скрытых дефектов. Приходите, мы восстановим справедливость.

Помните: каждый байт данных, каждая запись в журнале транзакций, каждая строчка ABAP-кода может стать решающим доказательством. Нужно только уметь их прочитать. Мы умеем. 🟩