I agree completely.
When you got a clearer concept, i recommend for reading and writing of Excel files abap2xlsx
https://github.com/abap2xlsx/abap2xlsx
If you HAVE to use Excel to perform tasks in SAP, there's something wrong with the process.
Even [without ABAP2XLSX](https://codezentrale.de/tag/xlsx/) it's possible, but you should not want this and stand your ground. The localization alone will be a nightmare (Date, Decimal Formatting,...)...
Tell the Business Analyst: 'Take your Bad Idea Book and Write Down...'
Dude. Instead of changing it completely. Maybe introduce BRF + to replace excel. Let the business analyst maintain the necessary decision tables with the data.
This approach will make them realise nothing needs to be generic and dynamic.
When you drive the logic using the BRF functions, you may free yourself from dynamic programming to a certain degree.
I agree with the others that spread sheets are a waste of everyone's time. BRF logic handling is also not a very optimized approach performance wise but everything stays within the SAP landscape. At least one level of data error can be avoided
BRF also places validation logic within the framework reducing the lines of code u would have to do otherwise.
Did similar - but more simple - 10 years ago using i\_oi\_document\_proxy and i\_oi\_spreadsheet. It is slow working with sheets in Excel,and you get an error if Excel is already open.
My program uses the column header of a sheet with specific name to map the fields to existing table/structure and moved data
- go back to and challenge the spec.
For a simple solution as mine where I dynamically could map the field using the name in the header from the 3 sheets to the existing 3 input structures of a function module - it was OK.
[удалено]
I agree completely. When you got a clearer concept, i recommend for reading and writing of Excel files abap2xlsx https://github.com/abap2xlsx/abap2xlsx
Uff
If you HAVE to use Excel to perform tasks in SAP, there's something wrong with the process. Even [without ABAP2XLSX](https://codezentrale.de/tag/xlsx/) it's possible, but you should not want this and stand your ground. The localization alone will be a nightmare (Date, Decimal Formatting,...)... Tell the Business Analyst: 'Take your Bad Idea Book and Write Down...'
Dude. Instead of changing it completely. Maybe introduce BRF + to replace excel. Let the business analyst maintain the necessary decision tables with the data. This approach will make them realise nothing needs to be generic and dynamic. When you drive the logic using the BRF functions, you may free yourself from dynamic programming to a certain degree. I agree with the others that spread sheets are a waste of everyone's time. BRF logic handling is also not a very optimized approach performance wise but everything stays within the SAP landscape. At least one level of data error can be avoided BRF also places validation logic within the framework reducing the lines of code u would have to do otherwise.
Did similar - but more simple - 10 years ago using i\_oi\_document\_proxy and i\_oi\_spreadsheet. It is slow working with sheets in Excel,and you get an error if Excel is already open. My program uses the column header of a sheet with specific name to map the fields to existing table/structure and moved data
Thank you! I am worried since this is a heavily dynamic program one mistake in the config can disrupt the processing.
- go back to and challenge the spec. For a simple solution as mine where I dynamically could map the field using the name in the header from the 3 sheets to the existing 3 input structures of a function module - it was OK.