Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

KWERT Calculation

former_member693583
Discoverer
0 Kudos

I was wondering how the KWERT field in KONV is calculated. I cannot find it anywhere and I know the KONV table isn't created until the report is run, but I'd like to know how and where KWERT is being calculated.

Thank you.

8 REPLIES 8

VeselinaPeykova
Active Contributor
0 Kudos

I am not sure what you mean by "I know the KONV table isn't created until the report is run". What report? And what is the process exactly?

Are you talking about sales order creation? Because after saving the order you have KBETR values in KONV.

If I understood you correctly, you are asking for the logic of SD or MM pricing.

Are you a developer? If yes, I would recommend that you speak with your functional SD or MM colleague for an introductory explanation of the concept (pricing can be quite complicated if you try to understand it only from development perspective).

If you want to dig deeper (after the functional consultant explains to you the general idea) - refer to this blog: Pricing Programs and their logic – Help for debugging.

0 Kudos

Sorry, had this dropped in my lap so I'm just trying to understand better. I understand that the KONV table is a cluster table that does not exist normally within SAP or at least within this instance of SAP. And yes the report is an Aged SO Report that I'm trying to understand as to how it's being created and what the fields are and where they come from..

sk-1759 I find it hard to agree with what you say about KONV. You can display KONV entries in SE16 (at least in SAP ERP), for S/4HANA it makes more sense to look at PRCD_ELEMENTS or use CDS views for reporting.

From what you explained so far, it seems that you are trying to understand the logic of some custom report.

It is next to impossible for community members to help you without having access to your system and without knowledge of the business processes.

If I were you, I would look for functional design and development design specifications - even if they are outdated, at least there will be some information on what they wanted to achieve at some point, why and how.

If you are a developer, really, you need a functional SD consultant from your team to assist you, it is not feasible to explain the concept of SD pricing in just 10k characters, the course on SD pricing is several hundred pages (and it just scratches the surface, the fun part starts with with custom fields, routines, exits).

In simple words: SD pricing (including KBETR) is influenced by multiple factors - master data, transactional data, configuration (item categories, copy controls, document types, pricing procedure, etc.), custom logic (routines, exits), hard-coded logic (done by SAP).

0 Kudos

Thank you for your reply. It really does help. My situation is exporting data to build a report outside of SAP. So knowing about the KWERT field and how to access it's value is important. I'm more of an outsider looking as I'm a developer, just not an SAP developer. But I am learning a lot.

lenastodal
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Scott,

If you feel that Veselina's answer helped you with your query, please feel free and accept it as best answer.
Best,
Lena (SAP Community Moderator)


Join or subscribe to SAP Community Groups to stay up-to-date, including SAP TechEd Group.

0 Kudos

sk-1759 in this case you definitely need a functional SD consultant from your company to assist you. Even experienced ABAP developers do not work without proper development specifications (prepared by functional consultants) for this kind of tasks.

Determining KWERT for a specific condition in a sales order is not difficult - you take KNUMV from VBAK and use it in KONV, but this does not mean that this is optimal solution for what your report is supposed to show, there are performance considerations, some conditions probably do not make sense to be shown, some items will probably have to be skipped, in certain cases you would prefer to use subtotal fields instead of retrieving values for some conditions and so on.

An outsider (here I mean a functional consultant with no knowledge of your system) can do more harm than good.

Ask for a development specification, it will take you longer to learn how SD pricing works in your system compared to the time it will take your SD colleague to write down what information you have to retrieve, from where and how.

0 Kudos

"you take KNUMV from VBAK and use it in KONV"

Can you please explain what you mean by this? I'm creating a proof of concept report and trying to get a close as possible to this.

Thanks.

0 Kudos

Scott Klein I meant the following: I have a sales order 13886 with item 10. I want to see the condition values for all conditions applied to this item. I use SE16 with table VBAK, I enter VBAK-VBELN = 13886 and determine VBAK-KNUMV = 0000080159.

Then I use the value for KNUMV in KONV as KNUMV and I also enter KONV-KPOSN = 10 (to restrict the result to item 10):

And I have KBETR (this is from a ECC system, I do not have PRCD_ELEMENTS table).

Again, please, get a knowledgeable SD consultant who has access to your system to help you!

For example, I use KONV only in specific cases, sometimes it is sufficient to use KZWI1-KZWI6 from VBAP.

There are also some specifics with currencies and different decimals if you read directly from KONV.

And I suspect that there may be more efficient ways to create the report which you have to build.