Прошу не отправлять в поиск сразу, я только что оттуда.

Проблема в тестовой системе. Перенос данных продолжался неделю, пользователи работали 2-3 дня при переносе.

Теперь при сохранении бух.документа с проводкой на 80* счет система выбрасывает экспресс-сообщение с ошибкой:
671: ABAP-процессор: SAPSQL_ARRAY_INSERT_DUPREC
Счетчики FI и CO проверил, в порядке эксперимента накрутил счетчик на 100 000, результат тот же.

Но при любой проводке, не создающей док-тов CO, бухгалт. документ создается.
Интуитивно чуй-ствую, что проблема с контроллингом, до счетчик-то в порядке...

Прошу посильной помощи.

Обратитесь к администратору и посмотрите лог update процесса. В таблицу вставляется дубль записи. Похоже просто нумерация CO документов сбилась. В логе будет написано какой диапазон номеров глючит

Хмм... В том-то и дело, что те счетчики, о которых я (бездарь и неуч без саповских курсов) знаю, проверены и в норме.

Dimkin, повторюсь, счетчик CO документов в норме.

Ошибка происходит в момент записи в таблицу GLPCA.
SM13,SE11,SE38 - мое все , копаюсь дальше.

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

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

Что у вас за система получилась при копировании с работой пользователей??? Странно, наш базисник за час систему копируют, да и работаем уже давно вроде в R/3

Так или иначе, решение должно быть. Столкнулся с тем, что SM13,ST22,SM21 ссыла.тся на строку кода
Что характерно, точка прерывания, установленная на этой строке (и во всем FORM) не срабатывает. Почему?

Оффтопиком:
Все разводят руками, когда слышат о копировании за неделю. Но это тема уже для Базиса, куда я вскоре и направлюсь .
А система получается вполне нормальная, главное иметь напильник драчевый под рукой для доточки.

Какая там может быть точка прерывания, если работает отдельный процесс обновления. Его и запускайте в отладке. Представьте, когда пользователь работает, он обновляет сразу данные в 100 таблицах, а копируются они последовательно, так что 50 таблиц у вас скопировались а 50 нет, и в тех таблицах где данные уже лежат, вставить новые записи с этим же ключом уже нельзя, вот и динамическая ошибка

Dimkin, а можно чуть поподробнее о запуске процесса обновления в отладке?

А какая версия системы, если не секрет?

Иногда помогает просто регенерация задействованных программ.

Попал под волну гриппа, потому пишу с задержкой.
1. Ошибка выскакивает при попытке сделать запись в таблицу GLPCA.
2. Генерация программ ни к чему не привела.
3. Базис решил накатить несколько апдейтов, до сих пор накатывают.
Будут результаты - отпишу.

1. Базис накатил все необходимые (по мнению базиса) апдейты.
2. Сгенерировали все программы.
3. Проверил еще раз счетчики (чем черт не шутит).
Итог - та же ошибка при записи в таблицу GLPCA.
4. Переиндексировал таблицу.
Проблема осталась.

Может быть, остались еще какие-то предложения по исправлению?
(сервер спиртовой салфеткой протирал, с бубном плясал, "ох щит" говорил)