I’m working with the MIRO transaction and need to customize the Payment section. Currently users can only select the Baseline Date field, but I want to give them the option to choose an Invoice Receipt Date field instead.
Has anyone successfully added custom fields to this area? I’m wondering if there are any Business Add-Ins (BADIs) or APIs that would allow this kind of modification to the payment block interface.
Any guidance on the technical approach or specific enhancement points would be really helpful. I’ve been looking through the standard configuration but haven’t found a straightforward way to extend these field options.
check user exit MRRL0001 - worked for me when i needed similar customization on payment fields. you might need to modify the screen structure too but its doable. also look into enhancement spot FI_INVOICE_POSTING if the user exit doesnt give you enough control
I ran into something similar last year when we needed additional date fields in the payment section. The approach that worked for us was implementing BADI FI_VENDOR_INVOICE_FIELDS which gives you more flexibility than the standard user exits. You’ll need to enhance table RBKP to include your custom Invoice Receipt Date field first, then use the BADI to make it available in the interface. The tricky part is ensuring the field validation works correctly with the payment terms calculation. Make sure to test thoroughly with different document types because some configurations can cause unexpected behavior in the posting logic. Documentation is sparse on this particular enhancement point so expect some trial and error.
We implemented a similar requirement through enhancement MM_MIRO_FIELDS combined with customizing the screen painter for transaction MIRO. The key was extending the payment block structure by adding the invoice receipt date field to the relevant structures and then modifying the screen layout accordingly. You’ll also need to handle the field population logic in the implementation class. One thing to watch out for is maintaining consistency with existing payment processing workflows since adding custom date fields can interfere with automatic payment proposal generation if not configured properly. The field needs proper validation against posting periods and fiscal year variants to avoid downstream issues.