12 Answers

• 00

  

  spaco 10/20/23, 12:28 PM

  Hello John,
  hoping that I have understood your question correctly: There is a field KNUMV in table VBRK, which you use to go to table KONV.
  Many greetings
  Ulrich

  report
• 00

  

  JohnLt (Author)10/20/23, 12:28 PM

  Hello Ulrich,
  Thank you very much for your quick feedback.
  However, it does not help me as it is. I have probably expressed myself unclearly. In addition, the terminology in SAP is not consistent here either.
  I was not interested in the sales conditions (PR00 etc.).
  I am more concerned with the account assignment type that is reflected in the account assignment analysis: "G/L account 123456 determined from account assignment type ABCD".
  From which table can I see the account assignment type used - ABCD in my example?
  Thanks and greetings
  John

  report
• 00

  

  spaco 10/20/23, 12:28 PM

  Hello John,
  have a look at the note 2474536.
  Many greetings
  Ulrich

  report
• 00

  

  JohnLt (Author)10/20/23, 12:28 PM

  Hello Ulrich,
  thanks for the hint.
  I already knew these includes (e.g. LV61C003 or LV61C002). But in our system there are some more includes defined, some of them were used.
  That is my problem: how do I find out which includes and therefore which account assignment type was used?
  Thanks and greetings
  John

  report
• 00

  

  spaco 10/20/23, 12:28 PM

  Hello John,
  the only term that currently comes to mind is "debugging".
  Many greetings
  Ulrich

  report
• 00

  

  MrBojangles 10/20/23, 12:28 PM

  Hello John,
  I don't know if the information about which account determination type was used for the billing document is persisted somewhere - I think rather not. I'm afraid you'll have to roll this up differently. So, for example, which billing types were used in the analysis period and which account determination procedure is assigned to them. Which conditions control the access to the account determination types contained in the schema....? Detective work...
  Have fun with SAP...
  Cheers
  MrB.
  Blog

  report
• 00

  

  danilongo1978 10/20/23, 12:28 PM

  Hello John,
  have you made any progress? How did you proceed now?
  I am at the interface between FI and SD and have had to do a bit in this area. I didn't quite understand what you were looking for. Maybe you can explain it again in more detail with a (further) example?
  Greetings
  Longes

  report
• 00

  

  JohnLt (Author)10/20/23, 12:28 PM

  Hello Longes,
  when I look in the VKOA, the wildest account assignments are defined from the history. We wanted to revise this now.
  Stupidly there are beside the usual condition types (C001-KSCHL) also some self-defined. So there is a user-exit behind each of them, but they were programmed very "creatively" again.
  So before we revise the account definitions, we wanted to find out which condition types have been used in the last 2-3 years.
  Then we would have deleted the account determinations that were not needed and only dealt with the condition types that were used.
  Again for clarification: it is not about the sales conditions, which are processed in VK11-VK13, but about the condition types, which are in the revenue account determination. Unfortunately, SAP's terminology is not consistent throughout.
  I hope I was able to explain what I am talking about :-)
  Thanks and greetings'
  John

  report
• 00

  

  danilongo1978 10/20/23, 12:28 PM

  So when I look in the VKOA, I first see umpteen default entries that could be deleted because they don't address our chart of accounts. Surely you don't mean those.
  You mean the account keys in the view KtoSchl?

  report
• 00

  

  JohnLt (Author)10/20/23, 12:28 PM

  I mean the "condition type for account determination" C001-KSCHL: e.g. KOFK, KOFX ...

  report
• 00

  

  Kadylac 10/20/23, 12:28 PM

  Hello John,
  Revenue account determination from VF02 is a dynamic determination. The information ERL condition type (and the rest of the access sequence) is always determined exactly at the moment when the function is called in dialog. A storage in a table does not take place in my opinion.
  This can also be traced by a performance trace over the SQL accesses. When creating a billing document or transferring it to FI, there is no update of this information in a table.
  Therefore to your problem the following 2 suggestions:
  1. write a Z-program for a mass account assignment analysis.
  In the dialog the account assignment analysis is called at the following place: SAPMV60A (form FCODE_KTPR).
  In the Z-program one would have to make the call, as in the dialog, per billing document and read the log table from the background with the results (there are all info like ERL condition type and account in it). There is certainly some analysis and development needed, but so you could actually determine all ERL condition types and all accounts accurately.
  
  2. selections backwards from the FI documents
  a. Have your FI colleagues give you a list of all the G/L accounts that have ever been posted (in the time period you want).
  b. Now search each of the Cxxx tables with these entries (e.g. C001-SAKN1 = list of G/L accounts).
  Result: You get all entries from the account determination that "could have led" to these accounts. The result is of course very inaccurate, because you get rather too many than too few results. But it depends very much on how the previous account determination was structured.
  The less often the same account appears in the C-tables, the more such an analysis makes sense.
  The more often the same account appears in the C-tables, the less useful the result.
  Note on the side (even though this is probably already clear):
  In general, the reorganization of an account determination is a very critical project, especially if you have worked past the standard due to additional programming. If the general conditions of your project are such that a complete function test of all account determination variants takes place at the end, then you can dare it. Otherwise, the question would rather be whether one divides the large total problem into smaller sub-problems and adapts individual blocks again and again. The effort for analysis and later for testing is very high in both cases.
  Good luck
  Kadylac

  report
• 00

  

  JohnLt (Author)10/20/23, 12:28 PM

  Hello Kadylac,
  Thank you for your detailed feedback.
  So, as feared, it will be more work than desired
  Greetings John

  report