I couldn't figure out a way to import transactions sanely into Yayoi Kaikei (the Quickbooks of Japan) to satisfy Japanese requirements for double-entry bookkeeping, so I implemented double-entry bookkeeping up to Japanese GAAP with about a dozen spreadsheets. It had to reconcile with information I got from a half-dozen systems, in varying formats. Also, most of the information coming in was in dollars, English, and either PST or GMT -- all three of which would get a look of disapproval from the Ogaki tax office -- so there's extensive use of historical lookup tables to massage the data to meet requirements without having to pay a bilingual bookkeeper to manually process everything.
If you add in the one-and-done Ruby scripts that I made to grab the information from the various computer systems and then spit out CSV for copy/pasting into Excel, this is unquestionably the worst bubble gum and duct tape programming job I've ever had the misfortune of participating in -- but it let me submit my tax return in time for the deadline, with numbers that looked pretty reasonable.
"bubble gum and duct tape programming job" – I guess you just found a name for the programming paradigm I plan to implement :)
As I understood in your case a system was a mix of what spreadsheets are good fit in (accounting) and where it is currently a kludge (gathering and massaging data).
So I think I'll explore data massaging in more depth. I am a bit concerned however with the representation of hierarchical data (like JSON) in spreadsheet model.
BTW, what were the main difficulties/problems in implementing your project using spreadsheets?
I assume that one of these was having to write Ruby scripts to connect things together instead of working directly with your data sources, was there anything else?
I have never had the need to do anything particularly complicated in Excel before, and had to learn how to express things that would have been very easy for me in Ruby, like "Servers, domain names, telephone bills, Twilio credits, and the like count as 通信費. Sum the total of all 通信費 given a list of all of your expenses for the past year."
Comments
I couldn't figure out a way to import transactions sanely into Yayoi Kaikei (the Quickbooks of Japan) to satisfy Japanese requirements for double-entry bookkeeping, so I implemented double-entry bookkeeping up to Japanese GAAP with about a dozen spreadsheets. It had to reconcile with information I got from a half-dozen systems, in varying formats. Also, most of the information coming in was in dollars, English, and either PST or GMT -- all three of which would get a look of disapproval from the Ogaki tax office -- so there's extensive use of historical lookup tables to massage the data to meet requirements without having to pay a bilingual bookkeeper to manually process everything.
If you add in the one-and-done Ruby scripts that I made to grab the information from the various computer systems and then spit out CSV for copy/pasting into Excel, this is unquestionably the worst bubble gum and duct tape programming job I've ever had the misfortune of participating in -- but it let me submit my tax return in time for the deadline, with numbers that looked pretty reasonable.
"bubble gum and duct tape programming job" – I guess you just found a name for the programming paradigm I plan to implement :)
As I understood in your case a system was a mix of what spreadsheets are good fit in (accounting) and where it is currently a kludge (gathering and massaging data).
So I think I'll explore data massaging in more depth. I am a bit concerned however with the representation of hierarchical data (like JSON) in spreadsheet model.
BTW, what were the main difficulties/problems in implementing your project using spreadsheets?
I assume that one of these was having to write Ruby scripts to connect things together instead of working directly with your data sources, was there anything else?
I have never had the need to do anything particularly complicated in Excel before, and had to learn how to express things that would have been very easy for me in Ruby, like "Servers, domain names, telephone bills, Twilio credits, and the like count as 通信費. Sum the total of all 通信費 given a list of all of your expenses for the past year."