[icebraining]

Can you explain a bit how do you see it being used? I mean, can you describe an hypothetical application using it?

The impression I get from the site is that you're essentially a hosted database with a predefined schema, but I'm guessing there's more to it.

Good luck on the project!

[whisk3rs]

I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.

Edit: spelling

[voidmain0001]

It's an accounting environment, and every system that provides goods and/or services needs to record the transactions in an accounting system. You can either use an existing accounting system such as Quickbooks, Freshbooks, Microsoft Dynamics, but then you're writing a document to those services rather than the underlying accounts forcing you to define the sales document's properties in the accounting system. In this case you should be able to keep your documents (sales invoice/credit memo) internal to your application, and the underlying account structure. In addition using Amatino should let you create accounting schedules in your application based off the ledgers. I guess you would use Amatino where you want more control over your accounting system, and I would imagine it costs less than the full-blown commercial offerings.

[icebraining]

Right, but recording transactions is the easy part; you can even take the schema from their docs, create a few DB tables from it, and just push to a local DB.

The reason to use a real accounting system is for the extra features (mainly reports), but I don't see them in this API, so you'd still need to export your data to one of those systems. So I'm struggling to see the advantage of pushing data to their service rather than to a local DB.

[voidmain0001]

More is required than a db schema; the double entry would have to be in app logic, permission model, aging, etc. Reports are nice, but in my experience I have always had to provide additional reporting on top of what is provided by an accounting system because the business had its own requirements. I see this being useful where you are trying to avoid a traditional accounting system because you willing to provide more customization.

[hughjeremy]

You put it better than I can, voidmain0001! I've so often been frustrated by being unable to extend an accounting system to suit my needs.

[hughjeremy]

voidmain0001 probably put it better than I can! To add to some more cents (pardon the pun): Amatino is aimed at a lower-level of the problem than reporting, GUIs, and such. Amatino provides capabilities far in excess of a self-rolled database, and allows developers to implement their wildest GUI / reporting dreams on top.

More time spent developing awesome applications, less time spent (for example) developing logic to recursively sum accounts in multiple currencies.

[hughjeremy]

Thank you for taking the time to look, icebraining! I'll try to answer briefly and not get too excited!

I see Amatino used as the unsexy, unsung, unseen double-entry data layer for other apps. Perhaps those apps are fancy GUI accounting apps like Xero, perhaps they are in-house bookkeeping systems, and so on.

Amatino saves the developers of such apps from having to develop their own double-entry systems, and provides them with a rich feature-set to draw on.