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: 

getting due date in MIRO based on ML81N custom field date

pashasapcha
Participant
0 Kudos
916

Good Morning, Gurus.

EARLIER i have created custom field of date type (default sy-datum ) using customer_exit in ML81N as shown below.

To achieve the above functionality, I have added new field to table ESSR so that the value gets stored in the table ESSR.

I have got new requirement in MIRO transaction. Under Invoice, payment tab , we have baseline date, payment terms , due on

fields.

I have to set validation in such a way that baseline date in MIRO, should be mapped with the custom invoice receive date field ZINVREDAT created on ML81N, and based on

pyt tems in MIRO the Due on date has to be default value.

To make it more clear,

whenever, user gets into the payments tab, the baseline value should be from the table ESSR-ZINVREDAT

and when the user selects pyt terms , the due date should appear by default.

if I select P042 in Pyt terms, the due on should be set to Baseline date , (ESSR-ZINVREDAT) + 7 days,

P043 = Baseline date (ESSR-ZINVREDAT) + 15 DAYS

P044 = Baseline date (ESSR-ZINVREDAT) + 30 DAYS.

The due on value should be by default while posting MIRO (faded) as it is already as shown below. .

How can I achieve this ?

9 REPLIES 9

raymond_giuseppi
Active Contributor
0 Kudos
821

Which of the 1156325 - BAdIs in the Logistics Invoice Verification environment did you already try, for example MRM_PAYMENT_TERM.

0 Kudos
821

I thought that MRM_PAYMENT_TERM suits my requirement as it contains base line date in exporting parameter. I have placed break point inside method . When I post PO using MIRO , the method is not triggered. I have checked the badi is active and also implementation is also active.

This badi is already in use. The code is already written. I have just placed session break point .

When we execute MIRO tcode , we are able to post the po, THIS METHOD is not triggered.

bUT MIRO IS POSTED successfully.

0 Kudos
821

Can you check if this implentation is already active, you could also set a break-point into MRM_FINAL_CHECK before the call.

0 Kudos
821

By using MRM_PAYMENT_TERM , I could able to get the date from the custom field of ML81N into the export parameter E_ZFBDT. I can see this in debugging mode as shown in the pic. But the problem is that it is not getting displayed in baseline date of MIRO transaction. It is showing blank.

Can someone tell me how to fix this and get the value in the baseline date ?

0 Kudos
821

Did you fill every export parameter (look at the SAP salmple with map those at start of implementing method from i_rbkpv)

0 Kudos
821

I don't want other parameters on to my screen as I will manually select the payment terms from the MIRO payment terms once the base line date gets appeared on to the screen. I got your point. Let me try , exporting the other parameters also with default values and check.

0 Kudos
821

I filled all the export parameters as shown below.

but I am not getting the baseline date from export parameter e_zbdlt on MIRO screen.

In debugging mode, I can see that the default input parameters are being passed into all the export parameters which I have added now.

Any idea what is stopping the value from e_zbdlt to move on to the MIRO screen when the badi is getting triggerred ?

Kindly please help me with this issue as I am working on it from a long time.

0 Kudos
821

Seems FI will overwrite your changes, try to add following code to prevent this behavior

cl_mrm_communication=>mv_zterm_badi_upd = 'X'.

(ref: KBA: 2601708 - MIRO: Baseline Date by BADI MRM_PAYMENT_TERMS overwritten

ajitkumar
Active Contributor
0 Kudos
821

you may keep the default value for base line date in payment terms as no default and see whether you an bring the date from service entry sheet using badi MRM_header_default. payment terms should default from origiinal purchasing document.