How to post to a sub-journal

[c-myers1]

So I created a sub-journal by the example here then added a transaction with a

...
"type": "SALES",
...

In the JSON body. I didn't see any difference in how it journalized this in the database vs the other transactions not posted to the subjournal.

How is it meant to work?

[abivia]

The journal_entries table should have a different value for subJournalUuid. If it doesn't, this is a bug. Upon reviewing the documentation, I'm thinking this might be an omission in the API. I'll write some tests here to verify.

[abivia]

Hold up. Use

"journal": "SALES",

In the request. Either way I don't have test coverage for this and the documentation isn't adequate. Writing a test now, if it passes I'll update the docs. If not, I'll fix the code, then update docs.

[c-myers1]

Ok but hmmm...I was under the impression AbiviaLedger is part of something larger you have been using in production which you just decided to open source, out of the kindness of your heart. Did you develop from scratch as-is? That would be noble indeed!

[abivia]

It was a bug. Fix in place, tests pass. Release coming.

Ledger is the basis for an in-house ERP that's under development, with the ultimate goal of replacing a proprietary system that's specific to Abivia's main business. It needs the multi-currency component (CAD/USD), but most of the other functionality is there because I've seen this problem tackled dozens of times over the years but always in some sort of specific context (ERP, ecomm, services billing) that either comes with features that are not needed or without capabilities that are. So Ledger aims to address everything required at the foundation, the rest is up to the application that uses it.

I've also seen innumerable applications with a financial component that are missing critical functionality (like basic double-entry recording) and I've seen the problems that result when it comes to integrating them with enterprise systems. Many of these were stop-gap measures where building a "proper" system would have taken too much effort. The goal here is to make it easier to drop in Ledger than it is to cobble together something that is a complete headache to integrate and audit.

So the "noble" goal, such as it is, is to try to make it easy for people to write applications that won't cause a CFO to curse the IT folks, and then demand hours of tedious work trying to retroactively fix the problems. That kind of work is far from fun. If I can save someone from it, I'm happy.

In a larger context, I'm hoping to build a component based ERP system. In part, that's what the Cogs package is about. It's still at tracking contacts and the like, the basis of CRM, but my hope is to expand it to invoicing, products, and beyond. By defining standard interfaces, the hope is that it doesn't matter if your products are dead simple (we sell this one widget, how many do you want) or incredibly complex (I have seen a supplier with 20+ attributes per SKU and 5,000 SKUs that brought Magento to it's knees), you should be able to plug in a ProductCatalog module that fits. I want to drive all this through APIs, so your product catalog could be local or located at Shopify; your customer info could be local or in Stripe or Salesforce. and most importantly if one of your SaaS suppliers decides to raise your costs beyond a reasonable level, that you can switch to another or bring the data in house without re-implementing everything from the ground up.

[abivia]

Fixed in 1.9.0.

[c-myers1]

I've also seen innumerable applications with a financial component that are missing critical functionality (like basic double-entry recording) and I've seen the problems that result when it comes to integrating them with enterprise systems.

Echo that!

All sounds good.