09-16-2014 2:09 PM
Hi all
I would like to simulate pricing conditions on SD invoice (already registered in FI). A bapi doing this particoular process would be great... but I cannot find nothing. Also a FM or BAPI to simulate/create without posting an invocice SD that return price conditions could be good: I tried BAPI_BILLINGDOC_CREATEMULTIPLE and BAPI_BILLINGDOC_SIMULATE, but KOMK is only in input and not in output. Does anybody have some hints ?
Thanks and regards
Gabriele
09-16-2014 4:03 PM
Solved. Here's the solution I found DIGGING in the standard program for bonus, processing and re-evaluating invoice (already in accounting). Hope this help who will have the same problem
PARAMETER vbeln TYPE vbrk-vbeln.
START-OF-SELECTION.
DATA wa_vbrk TYPE vbrk.
DATA xkomv TYPE TABLE OF komv.
DATA xvbpa TYPE TABLE OF vbpavb.
DATA xvbrk TYPE TABLE OF vbrkvb.
DATA xvbrp TYPE TABLE OF vbrpvb.
DATA xkomfk TYPE TABLE OF komfk .
DATA xvbfs TYPE TABLE OF vbfs .
DATA xvbss TYPE TABLE OF vbss .
SELECT SINGLE *
FROM vbrk
INTO wa_vbrk
WHERE vbeln EQ vbeln.
CALL FUNCTION 'RV_INVOICE_DOCUMENT_READ'
EXPORTING
activity = '02'
konv_read = 'X'
no_nast = 'X'
vbrk_i = wa_vbrk
i_no_authority_check = 'X'
TABLES
xkomv = xkomv
xvbpa = xvbpa
xvbrk = xvbrk
xvbrp = xvbrp
xkomfk = xkomfk
EXCEPTIONS
error_message = 4
OTHERS = 4.
DATA vbsk_i TYPE vbsk.
DATA vbsk_e TYPE vbsk.
DATA xkomk TYPE TABLE OF komk.
DATA xkomp TYPE TABLE OF komp.
DATA xthead TYPE TABLE OF theadvb.
CALL FUNCTION 'RV_INVOICE_DOCUMENT_UPDATE'
EXPORTING
vbsk_i = vbsk_i
pricing_type = 'B'
IMPORTING
vbsk_e = vbsk_e
TABLES
xkomfk = xkomfk
xkomk = xkomk
xkomp = xkomp
xkomv = xkomv " <====== NEW CONDITION HERE !!
xthead = xthead
xvbfs = xvbfs
xvbpa = xvbpa
xvbrk = xvbrk
xvbrp = xvbrp
xvbss = xvbss
EXCEPTIONS
OTHERS = 1.
09-16-2014 2:24 PM
09-16-2014 2:27 PM
Hi
That BAPI returns the conditions, these should be the data you need, KOMK is the table to transfer the header data for pricing calculation
Max
09-16-2014 3:53 PM
RV_INVOICE_DOCUMENT_READ returns the conditions as they are in VF03. This is not what I need. I'll try to explain e bit better the situation: I need to apply new condition to invoice already in accounting (as simulation). It's like my program return value of conditions as they were in invoice when registering it.. When invoice was registered, conditions did not exist (so they're not present in KOMK). Let me know if I have been clear ...
09-16-2014 4:03 PM
Solved. Here's the solution I found DIGGING in the standard program for bonus, processing and re-evaluating invoice (already in accounting). Hope this help who will have the same problem
PARAMETER vbeln TYPE vbrk-vbeln.
START-OF-SELECTION.
DATA wa_vbrk TYPE vbrk.
DATA xkomv TYPE TABLE OF komv.
DATA xvbpa TYPE TABLE OF vbpavb.
DATA xvbrk TYPE TABLE OF vbrkvb.
DATA xvbrp TYPE TABLE OF vbrpvb.
DATA xkomfk TYPE TABLE OF komfk .
DATA xvbfs TYPE TABLE OF vbfs .
DATA xvbss TYPE TABLE OF vbss .
SELECT SINGLE *
FROM vbrk
INTO wa_vbrk
WHERE vbeln EQ vbeln.
CALL FUNCTION 'RV_INVOICE_DOCUMENT_READ'
EXPORTING
activity = '02'
konv_read = 'X'
no_nast = 'X'
vbrk_i = wa_vbrk
i_no_authority_check = 'X'
TABLES
xkomv = xkomv
xvbpa = xvbpa
xvbrk = xvbrk
xvbrp = xvbrp
xkomfk = xkomfk
EXCEPTIONS
error_message = 4
OTHERS = 4.
DATA vbsk_i TYPE vbsk.
DATA vbsk_e TYPE vbsk.
DATA xkomk TYPE TABLE OF komk.
DATA xkomp TYPE TABLE OF komp.
DATA xthead TYPE TABLE OF theadvb.
CALL FUNCTION 'RV_INVOICE_DOCUMENT_UPDATE'
EXPORTING
vbsk_i = vbsk_i
pricing_type = 'B'
IMPORTING
vbsk_e = vbsk_e
TABLES
xkomfk = xkomfk
xkomk = xkomk
xkomp = xkomp
xkomv = xkomv " <====== NEW CONDITION HERE !!
xthead = xthead
xvbfs = xvbfs
xvbpa = xvbpa
xvbrk = xvbrk
xvbrp = xvbrp
xvbss = xvbss
EXCEPTIONS
OTHERS = 1.
09-16-2014 4:07 PM
I don't understand what you want
The BAPI for simulation returns the pricing so why it's not good for you?
Max
09-16-2014 4:20 PM
What is the Business requirement for this? Not sure whether you are aware of how system behaves functionally. As and when a billing document generates, system would fetch the pricing either from sale order or from condition record based on the copy control settings in TVCPF table where if "B" is maintained against the field KNPRS, system would fetch pricing from KONP table; else, it would fetch from sale order (KONV table).
G. Lakshmipathi
09-16-2014 6:42 PM
This is the business scenario: an SD invoice is created. Every price conditions is fetched from order (delivery) into VBRK document. Invoice is registered in FI (SD invoice not modifiable). Time (months) pass. User create / modify / delete conditions (also the ones gone into above invoice). And also, users chenge customer (of the above invoice) position in customer hierarchy with VHD1N (this means that all hierarchical price conditions are lost for invoices created after hierearchy update). What I need was to simuate again the invoice price conditions so that conditions belonging to invoice are evaluated with new values user set (after accounting), and other conditions (hierarchical, valid at invoice date) remains.
I tried to create/simulate new invoice with date of the old, with BAPI above mentioned, but functions give me no conditions in output (I saw that tables name in interface had "_in" trailer and I thought it were only in input, but also could have been because I tried to create invoice without reference to order and so conditions were not copied). So I thought to simulate a new order with date = invoice date and read conditions (in someway) from order simulation. There's a problem: simulation bapi read customer hierarchy at sy-datum. there is an oss note saying this is the normal working of the system (also in VA01 setting document/price date) (I ask myself why... there is validity in KNVH - customer hierarchy table..). I don't know if I miss something in my tests, but this was the situation I was trying to resolve on sdn when I wrote the post.
My last idea has been this: Sap standard provides functionality I was looking for, in agreement handling (KONA and so on...), so I read the program that executes this task and I found where "old" invoice were re-evaluated. The above code it's (quite) what Sap standard do and works perfectly: evaluates again conditions updated (after invoice accounting) and apply hierarchical conditions valid at invoice date (and not today).