cancel
Showing results for 
Search instead for 
Did you mean: 

How to clean up output determination condition tables

TMNielsen
Contributor
0 Kudos

Hi

We have some cluttered data in some conditions tables like B001 and corresponding entries in tabel NACH.

For example we have a record in B001 for invoice output type ZD00, but when we look at output type ZD00 it is linked to an access sequence that does not contain any step (access number) with ref. to table 001 (B001).

This is very disturbing because we often look into table NACH to analyse output determination issues.

Unfortunately this also means that it is not possible to find and delete these records in transaction VV32.

How can we delete these lost (orphan) entries?

Accepted Solutions (1)

Accepted Solutions (1)

andrea_brusarestelletti
Active Contributor
0 Kudos

Hello,

perhaps this happened because those entries were made when table 001 was assigned in the acces sequence, or to an access sequence previously assigned to condition ZD00, and the removed.

You can try to assign table 001 again to check if this way you can get the entries through VV32, delete them and then remove table 001 again. Otherwise, you can develop your own report to check consistency between entries in B001 and NACH tables: as far as I know no standar report exists which clean these tables.

Best regards,

Andrea

TMNielsen
Contributor
0 Kudos

Hi Andrea

Thanks for your answer.

I think there are not inconsistency between B001 and NACH.

The inconsistency is between B001 and NACH on one side, and the access sequence on the other side. However I would not like to develop a report to delete inconsistent entries, because this is SAP standard tables, and I don't have complete overview of which tables are linked together. The risk is that I just create worse inconsistencies.

I have considered the other method, by assigning tabel 001 and then delete entries in VV32. This approach is however also difficult. Because I actually have the same problem with more than just table 001, and the re-assignment of tables requires transport from development system (this is in our environment a slow process). But so far it seems to be the only solution.

andrea_brusarestelletti
Active Contributor
0 Kudos

Hello,

I understand both your concerns.

For the first one, you can put under trace the creation of a record message and with the help of an ABAPer, try to understand all the tables involved: perhaps it could be only the two mentioned.

The second option is quite tricky, and I understand that is complex if you have more different condition tables involved. But if it works, it should grant that the deletion procedure is the standard one.

Best regards,

Andrea

Answers (0)