Your problem is application performance, not IDoc performance!
I see that you apparently have already decided to process the IDocs in a batch run using RBDAPP01. From there on you are already beyond the interface processing and are within the application, i.e. everything that happens now is due to the processing application, in your case the SAPMV45A application. Parallel processing the IDocs is possible just by planning several RBDAPP01 simultaneous jobs. You would need an intelligent mechanism that guarantees that each jobs picks its own pile of IDocs to process. However, this will not solve your performance problem unless you have several app servers and have every job running on a separate box. There may be locking problems if the IDocs share same material master , customer master data etc, so this may become a difficult enterprise depending on the nature of your data.
I suggest you first try to analyze the IDoc processing performance to find out where the time is lost. This can be done by executing transaction SE30 or the program RBDAPP01 and a single IDoc. Then analyze the result and judge if there are sections that have a long processing time. Have a special look on user-exits and unexpectedly long database selects.
If this does not really help, there is still the old advice from Mama Blue: "Buy a bigger machine!"
Dig Deeper on SAP ABAP
Related Q&A from Axel Angeli
An SAP user is receiving an error message while integrating SAP iDoc PORDCR1 for a purchase order. Continue Reading
SAP expert Axel Angeli explains how to update the "further dates" tab information in am SAP transaction through an SAP IDoc. Continue Reading
An SAP R/3 4.7 user wants looking to post a document entry using different trading partner fields for credit and debit for function FB01. Continue Reading