При анализе дампа выбранные переменные имеют такие значения (ну не силен я в АВАРе

Table[initial]
DD08V_TAB-TXTTABNAME
T005T
533352222222222222222222222222
400540000000000000000000000000

DD08V_TAB-REFFLDNAME
LAND1
444432222222222222222222222222
C1E410000000000000000000000000

DD08V_TAB-CHECKTABLE
T005
533322222222222222222222222222
400500000000000000000000000000

DD03V_TAB-FIELDNAME
LAND1
444432222222222222222222222222
C1E410000000000000000000000000

Ну и можно проваливаться еще внутрь значений...

А большое это значение для сервера или маленькое сказать не могу...

Да и в нотах такого дампа не находим для SAPLV12A

T005 - это таблица с обозначениями стран, т.е. там ну никак не может быть больше записей, чем стран на земле (максимум несколько сотен). Думаю дело не в ней, а dump происходит из-за того, что где-то ДО того программа работает очень долго. Попробуйте SQL Trace - транзакция ST05, Activate Trace with Filter (укажите фильтр по своему user ID), а потом, когда транзакция вылетит в дамп, Deactivate Trace и Display Trace. И там смотрите записи, которые красным цветом (вернее эдаким розовым) выделены.

Если и там ничего подозрительного нет, то тогда надо прогнать транзакцию через Runtime Analyzer. Еще можно следить за SM50 пока транзакция работает, там будет видно, если на одном месте долго застревает. Спросите у базисника, сколько у вас времени отведено до time out (у нас около 10 минут). Вообще базисник или ABAP'ер вам бы могли помочь с этим.

Попробовал ST05 посмотрел, там несколько "розовых" мест. Без поллитры не разберешь, а базисники это мы сами. Решили ставить просто патчи обновлений, пока систему не попустит. После двух патчей, стали сохраняться фактуры, но все равно не деблокируются, теперь пишет просто:

Документ 90000001 сохранен (ошибка при поиске счета)

Естественно, что все счета прописаны выручка, касса, контрольные, для налоговкоды тоже. Мистика... Продолжаем танцевать с бубном (ставить патчи).

После обращение в службу поддержки порекомендовали в DB13 запустить statistics optimizer. Порекомендовали и ноты:

According your dump the problem is in performance of table.

To avoid such a problem please schedule regular statistics update jobs

via TA: DB13. For further information please see SAP Note 927882.

Also, look at recomendations from notes:

767635 MaxDB Version 7.5 parameter settings for OLTP/BW

808060 Changing the estimated values for Update Statistics

Запустили и дамп исчез!




Настроил пустые поля условий MWST в VK11, вошел в изменение фактуры VF02 и попытался деблокировать ее для бухучета, но все равно выскакивает сообщение:

"Документ 90000003 сохранен (ошибка при поиске счета)"

Что за счет ему не хватает? Подскажите, пожалуйста?

Ну это ваш Basis мог бы уже и догадаться...



Это сообщение ни нам, ни вам ни о чем не говорит. Вы попробуйте зайти в VF02 и в первом меню запустить Release to Accounting. Тогда выскочит сообщение, где будут конкретные значения, по которым SAP ищет запись. От них и танцуйте.

Я, честно говоря, не специалист, но, насколько помню, в VK11 указывается условие и там еще есть поле Tax Code (например, A0, A1 и т.п.). По условию SAP находит этот code и потом уже дальше ищет, какие счета и прочая присвоены. Тут также имеет место конфигурация на стороне FI - транзакция FTXP.

Вообще если кто-нибудь мог бы подсказать хороший документ по конфигурации налогов (SD + FI), то было бы здорово - у нас постоянно возникают какие-то заморочки с этим и я до конца всей этой системы так и не поняла. А SD специалиста у нас нет.

чаще всего счета выручки:
Сбыт - Основные функции - Контировка/калькуляция - Выбор счетов выручки - Присвоение основных счетов