List Of Spreadsheet Horror Stories
One of the things the European Spreadsheet Risks Interest Group likes to do is collect horror stories about the (mis)use of spreadsheets <http://eusprig.org/horror-stories.htm>. Found the link in a reader comment <https://forums.theregister.co.uk/forum/all/2020/05/19/sap_analytics_cloud_office_integration/#c_4035088> to this article <https://www.theregister.co.uk/2020/05/19/sap_analytics_cloud_office_integration/> about how software company SAP, creator of a complete business analytics suite, has felt compelled to include an interface to Microsoft Excel, just because that’s what most of its customers are familiar with.
felt compelled to include an interface to Microsoft Excel,...
Interesting that SAP's front end sucks so much that there is money to be made selling Excel as the data entry interface. It seems that this has also been the case with Orcale ERP. For 20 years a Hamilton based company has been globally selling their Excel data entry front end to Oracles product suite. The company is called More4Apps<https://more4apps.com/> and their products utilize thousands of lines of Visual Basic for Applications ( VBA<https://en.wikipedia.org/wiki/Visual_Basic_for_Applications> ) code running in the Excel spreadsheets they provide. I've often wondered if they would be better off to switch from using the Excel / VBA combination to Calc<https://simple.wikipedia.org/wiki/OpenOffice_Calc> / PyUNO Bridge<https://wiki.openoffice.org/wiki/PyUNO_bridge> / Python3 and that way they avoid having to use VBA. cheers, Ian.
On Thu, 21 May 2020, at 08:27, Ian Stewart wrote:
The company is called More4Apps <https://more4apps.com/> and their products utilize thousands of lines of Visual Basic for Applications ( VBA <https://en.wikipedia.org/wiki/Visual_Basic_for_Applications> ) code running in the Excel spreadsheets they provide.
I've often wondered if they would be better off to switch from using the Excel / VBA combination to Calc <https://simple.wikipedia.org/wiki/OpenOffice_Calc> / PyUNO Bridge <https://wiki.openoffice.org/wiki/PyUNO_bridge> / Python3 and that way they avoid having to use VBA.
Heh as someone who used to run a competing business to More4Apps, also in the Excel/VBA space... We did experiment with the Calc / Uno journey (no Python at the time); it was an expensive and fruitless lesson. VBA was a far better contender, even though it is an antiquated language with a truly lacking IDE. That said, another one of my projects I was able to convert much of my VBA into Python using xlwings. That was a really excellent experience which I'd definitely use again. E -------------------------------------------- Q: Why is this email five sentences or less? A: http://five.sentenc.es On Thu, 21 May 2020, at 08:27, Ian Stewart wrote:
felt compelled to include an interface to Microsoft Excel,...
Interesting that SAP's front end sucks so much that there is money to be made selling Excel as the data entry interface.
It seems that this has also been the case with Orcale ERP. For 20 years a Hamilton based company has been globally selling their Excel data entry front end to Oracles product suite.
The company is called More4Apps <https://more4apps.com/> and their products utilize thousands of lines of Visual Basic for Applications ( VBA <https://en.wikipedia.org/wiki/Visual_Basic_for_Applications> ) code running in the Excel spreadsheets they provide.
I've often wondered if they would be better off to switch from using the Excel / VBA combination to Calc <https://simple.wikipedia.org/wiki/OpenOffice_Calc> / PyUNO Bridge <https://wiki.openoffice.org/wiki/PyUNO_bridge> / Python3 and that way they avoid having to use VBA.
cheers, Ian.
_______________________________________________ wlug mailing list -- wlug(a)list.waikato.ac.nz | To unsubscribe send an email to wlug-leave(a)list.waikato.ac.nz Unsubscribe: https://list.waikato.ac.nz/postorius/lists/wlug.list.waikato.ac.nz
The company is called More4Apps and their products utilize thousands of lines of Visual Basic for Applications ( VBA ) code running in the Excel spreadsheets they provide.
I've often wondered if they would be better off to switch from using the Excel / VBA combination to Calc / PyUNO Bridge / Python3 and that way they avoid having to use VBA.
Heh as someone who used to run a competing business to More4Apps, also in the Excel/VBA space...
We did experiment with the Calc / Uno journey (no Python at the time); it was an expensive and fruitless lesson. VBA was a far better contender, even though it is an antiquated language with a truly lacking IDE.
That said, another one of my projects I was able to convert much of my VBA into Python using xlwings. That was a really excellent experience which I'd definitely use again.
That looks like a really cool project! Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/
On Wed, 20 May 2020 20:27:06 +0000, Ian Stewart wrote:
Interesting that SAP's front end sucks so much that there is money to be made selling Excel as the data entry interface.
Not sure if the SAP code sucked that much (in this case), more that companies are so familiar with Excel they refuse to give it up for something better.
I've often wondered if they would be better off to switch from using the Excel / VBA combination to Calc<https://simple.wikipedia.org/wiki/OpenOffice_Calc> / PyUNO Bridge<https://wiki.openoffice.org/wiki/PyUNO_bridge> / Python3 and that way they avoid having to use VBA.
A few weeks ago I tried to see if I could produce a grid-of-cells-type display using Jupyter+Python. For example, a mortgage or fixed-deposit payment schedule, where you can try the effect of different interest rates, payment amounts etc--something that is quite commonly done with spreadsheets. That actually worked nicely: I could put up some simple input fields for the starting numbers, plus some radio buttons or checkboxes for options like calculating interest in advance (start of each payment period) or arrears (end of each payment period), so these are the only things the user can modify (apart from the cells containing the Python code, which hopefully they won’t touch). The output cells are, of course, read-only, so no chance of introducing subtle bugs by modifying them. And for those who want charting, Matplotlib offers more charting options than Excel has ever heard of.
...Continuing on the Calc/PyUNO/Python theme, an idea that I had some years ago was: A blank Calc spreadsheet is really just a bunch of folders and files zipped to make a file that's given a .ods extension. For example if I unzip a calc file this is what's in it... blank-calc-spreadsheet.ods ├── Configurations2 │ ├── accelerator │ ├── floater │ ├── images │ │ └── Bitmaps │ ├── menubar │ ├── popupmenu │ ├── progressbar │ ├── statusbar │ ├── toolbar │ └── toolpanel ├── content.xml ├── manifest.rdf ├── META-INF │ └── manifest.xml ├── meta.xml ├── mimetype ├── settings.xml ├── styles.xml └── Thumbnails └── thumbnail.png In theory all these files, and many more that you've created, could exist in a data base. A python program would run that opens the database and builds a calc spreadsheet .ods file to the desired specifications using a selection of components from the database. Thus every spreadsheet created could be unique, have a serial number, have the end Users name and address embedded in it, include BASIC or Python code, and provide a specific set of features just for that User. While PyUNO would be used to initially create the file, there is no reason why the file can't stand on its own feet after its creation and use code that's embedded into it rather than having to make a PyUNO connection. In theory, every spreadsheet you create is unique. I've no idea if this has market potential or not, but from that analysis I did at the time I figured it couldn't be done with the Excel/VBA/whatever combination. cheers, Ian.
participants (4)
-
Eric Light -
Ian Stewart -
Lawrence D'Oliveiro -
Peter Reutemann