Коллеги,
помогите, пожалуйста, с довольно банальной (но для меня так и не понятной) проблемой.

Среди огромного перечня документов, проводимых он-лайн в FI-SL, стабильно 1-2 документа в месяц валятся в unclass (причем все они ММ - доки).
При переносе задним числом они закачиваюся без проблем.
Настройки иерархии не менялись, осн. данные материала, которые анализируются в критериях иерархии - тоже.
Проверяла open-fi, замещения - нигде не найти концов....
Сравнивала корректно проведенные и некорректные - вся аналитика идентична ( я имею в виду "вид операции" и прочие поля ztaxrega)...
Системный глюк/сбой?
Уверена, что хотя бы раз это случалось со многими. Какими вы видите причины подобных сбоев и способы их устранения?
В моем случае не понятна стабильность таких unclass-ов.

Огромное спасибо всем, кто откликнется.

Татьяна.

Какие критерии отбора у вас используются?

Для необходимого ЭНУ:
Счет ГК (интервал), вид движения ACCIT_GLX - BWART (тоже интервал), тип материала MARA - MTART (набор из 3х значений)

Для UNCLASS:
Счет ГК (интервал), заказ ACCIT_GLX - AUFNR (маска)

тип материала точно передается в ACCIT, в отладке смотрели? Если да - то проверьте еще вот что: в ФМ J_3RF_TAX_SELECT_OBJ_FI, FORM CHECK_SO у вас дважды анализируются все критерии отбора, выкачанные их иерархии - сначала против счета, потом против доп. полей. Так вот - поскольку поле AUFNR в списке критериев по порядку стоит выше, чем BWART и MTART - вполне вероятно, что в документах, где есть и счет, и материал, и вид материала (а те документы, которые у вас не классифицируются, как раз такие, я правильно понимаю?), первым по порядку у вас анализируется именно ключ HKONT-AUFNR, а только потом (в теории) - HKONT-BWART и все остальные, следовательно исходя из настройки иерархии первым у вас находится значение ЭНУ UNCLASS. После этого дальнейшие проверки уже не производятся, соот-но - у вас документ в анкласс и валится.

Вообще - эта проблема возникает на случайных документах ММ, или же всегда относится к какой-то одной операци и/или схеме проводок?

-TT-, спасибо за подсказку с ФМ - внимательно проверю, напишу о результатах.
Проблема еще в том, что в unclass попадают случайные документы ММ (а не какая-то конкретная операция и/или схема проводок)....

Не должно такого быть, т.к. UNCLASS прибавляется в конец LT_OBJSEL и его критерии всегда проверяются последними.

Они проверяются последними, поскольку изначально предполагается, что в качестве критерия к UNCLASS используется только счет, поэтому в самом конце, если b_ok<> "да, конечно, все отлично" - то ставится анкласс. А так - в чек-соу передается вся таблица с критериями отбора, против которой выставляются последовательно счет и все допы по алфавитному порядку. Вот порядок скорее всего и сыграл в данной ситуации в пользу анкласса.

Дебажте модуль. Проблема вероятнее всего там.

Возможно у вас J_3RF_TAX_SELECT_OBJ_FI отличается от моего, но у меня в CHECK_SO никаких таблиц не смотрится, там примитивная проверка, что значение удовлетворяет критериям. При этом сначала проверяется счет, и если счет подходит, то только для этого ЭНУ отбираются критерии отбора по дополнительным полям.

Но, по моему, это даж не важно, т.к. программа одинаково работает что онлайн, что задним числом.
Обычно такие проблемы возникают, когда структуры которые анализируются, по разному заполнены при проводке онлайн и задним числом. Нужно смотреть какие значения полей приходят в J_3RF_TAX_SELECT_OBJ_FI.

Так а что передается в чек соу? с откуда чек соу берет значения для сравнения с зеркалом ACCIT'a? Из таблички с критериями отбора (системы под рукой нет, J_что-то-там_OBJSEL). И туда заказчивается J_что-то-там_OBJSEL в полном объеме, после чего луп выставляет каждую строку обжсела против зеркала асита. И если он находит по ключу HKONT-AUFNR (первому из возможных по порядку) значение UNCLASS - он его и возмет в node_code.

Так а что передается в чек соу? с откуда чек соу берет значения для сравнения с зеркалом ACCIT'a? Из таблички с критериями отбора (системы под рукой нет, J_что-то-там_OBJSEL). И туда заказчивается J_что-то-там_OBJSEL в полном объеме, после чего луп выставляет каждую строку обжсела против зеркала асита. И если он находит по ключу HKONT-AUFNR (первому из возможных по порядку) значение UNCLASS - он его и возмет в node_code.

В ФМ J_3RF_TAX_SELECT_OBJ_FI выбираются данные из j_3rftax_objsel с заполненным ограничением по счетам, причем таким образом, что ЭНУ UNCLASS добавляется в конце внутренней таблицы LT_OBJSEL. Потом в цикле выполняется проверка на соответствие счета в LT_OBJSEL и ACCIT_GLX, для чего вызывается CHECK_SO в который передается 4 параметра:
Счет из ACCIT_GLX
Опция выбора
Нижнее значение
Верхнее значение

И если в соответствии со счетом ЭНУ подходит, то только тогда из j_3rftax_objsel подкачиваются критерии выбора для дополнительных полей причем только для текущего ЭНУ (objsel-node_code ) и конкретной строки критериев выбора (objsel-linenum)
* Additional fields check
SELECT * INTO TABLE lt_addfields
FROM j_3rftax_objsel
WHERE hier_key = hier_key AND
node_code = objsel-node_code AND
linenum = objsel-linenum AND
SEQNR <> OBJSEL-SEQNR.

и для каждого дополнительного поля опять вызывается CHECK_SO.

Поэтому ЭНУ Unclass, всегда будет проверяться последним, при условии, что он прописан в табличке J_3RFTAX_UNCLASS.

Данные для классификации хранятся в таблице БД j_3rftax_objsel.
Данная таблица является буферизуемой. Тип буферизации – Generic Area, критерий – 2 ключевых поля.

Это означает, что при первом обращении к ней буферизуются все записи, которые подходят по первым двум ключевым полям согласно параметрам обращения.
Первые два поля – это мандант и код иерархии, то есть при обращении к иерархии XXXXX она вся сразу попадает в буфер.

Алгоритм функционального модуля J_3RF_TAX_SELECT_OBJ_FI выбирает записи из данной таблицы и, как верно было замечено, не сортирует их.
При первом обращении действительно всё выглядит печально: все ЭНУ вперемешку в произвольном порядке.
Но после того, как всё забуферизовалось, при следующем обращении, результат сортирован по алфавиту.
Это происходит из-за того, что в буфер данные попадают уже сортированными.

Если элементы для UNCLASS записаны в табличке J_3RFTAX_UNCLASS, то они идут всегда последними, это было отмечено ранее. А если нет - то могут попасть и в начало выборки!
То есть известный всем постулат, что классификация идет сверху вниз верен не на все 100%.

Мне кажется, причина вашей беды именно в этом. У вас пару раз в месяц сбрасывают буферы таблиц (перегружают сервер или через ST02).
После этого первая классификация проходит как бог на душу положит, а далее всё идет нормально.
Это решается одним из двух методов:
1. Все ЭНУ должны иметь взаимоисключающие условия (и UNCLASS должен быть прописан в J3RTAXUC)
2. Исправить ФМ, добавив принудительную сортировку по коду ЭНУ.