HI Sumanth,
this already occured to me, but here's the thing:
1) there's no YVBAK here.
2) there is an XVBAK here which you can compare with previously saved VBAK entry in the database
3) this '2)' is only gonna work if you process the output record immediately after saving the order. if you have a situation where you just trigger the output record during saving and process it later by a batch-job(RSNAST00, then XVBAK will have the same values as the ones saved in VBAK in the database. so you will not be able to capture the change and the idoc will never be dispatched, because you will have coded to terminate the process if there are no changes)
4) even if there are no changes, ZACK still gets triggered and IDOC_OUTPUT_ORDERS, still gets called. Further more the exit is at the end of the FM source code, which means it has gone through tons of code and is already ready to send the idoc, when you decide to terminate it. 
5) in case you use the VOFM solution, you have the efficiency, that you do not create a ZACK at all if you havent changed ZMBDAT
6) further if you do change it, ZACK gets triggered. then it wont matter if you send the idoc immediately or via a job, because it was already established the ZMBDAT was changed on the order.
if you still want to check for changes in the date in a user exit, my suggestion is to use EXIT_SAPLVEDC_004 since it gets called at an earlier stage in IDOC_OUTPUT_ORDRSP and you can save some execution effort for the system if you terminate it here.
also i wanted to let you know that if you are processing ZACK immediately after saving the order, then it will be done in an update task, the only way to find out if the order was in create mode or change mode is to check if XVBAK-AENAM and XVBAK-AEDAT are not initial. you wont have luck if you use sy-tcode.
br,
Nikhil Rao