Comment by journal

Comment by journal 10 months ago

5 replies

I have a few ideas in the works for accepting contributions that I will iron out in the coming days. I have some breaking changes in the works to make the journal more reliable and testable. The current implementation requires deep understanding of my vision.

AFAIK, North Korea, Russia, and United States, all have the same five accounts types and require double-entry.

This truly is a mission to rebuild an institution. My goal is to educate a new generation of accountants. The kind who can produce any report from raw journal entries and who can add new features to the journal.

Parent-child relationships help with reporting, but I notice the need to include parent-child relationships almost everywhere; locations, items (products/services), chart-of-accounts, users, tasks, etc.

I've not touched reporting because I know it will be easy to do.

If I get the journal, accounts, and transactions right, the rest is easy street.

One thing to mention at this time is that I don't see a need to manually enter journal entries. I'm ready to catch flack for saying this, but maybe... idk. Still in R&D phase.

karl11 10 months ago

Lack of manual journals would be a non-starter, I am actually not clear how a business could possibly run their books without manual journals.

An example: you make something that uses 5 inputs. I have inventory and cost of goods sold accounts for each of those inputs, but my invoices out to customers only reference the final product. This is where ERPs add insanely complex inventory management solutions. However, the simple way to deal with it instead is to use a manual journal to reconcile your inventory and cost of goods sold accounts monthly or however often you like.

  • j45 10 months ago

    Interesting example - Complex ERP inventory management and manufacturing experience here:

    It seems reasonable to need manual adjustments, but I'm not sure if entries would be needed. Deciding how to make corrections and adjustments seems to be key in any manual journal entries, or not.

    If journal entries derive from transactions elsewhere, chaining those together, or something to adjust them them is pretty reasonable.

    About split entries like the scenario you've outlined? Cost of Goods Sold, vs manufacturing are all often in different parts of the ERP that may not tie back to journals always. Perhaps there is a pattern to setup that is repeatable. I'm not sure if you have a software background, but source code control of managing the bits of what changed when is important.

    Another scenario where manual stuff might not work is if we have a just in time manufacturing process, and don't complete the finished goods until the items are on the truck and signed for by the driver (un damaged) so then you can finalize manufacturing, invoicing, shipping documents, etc. There's ways to reduce having to undo all of those if product is damaged between manufacturing and shipping. Of course this has it's own caveats. Implemented OK in SAP though.

    Overall, a real need and goal is: reducing the amount accountants or anyone who works with an accounting data has to dump out data from the accounting system to "manipulate the data" to get a view of what happened/happening/needs to happen.

    Unpopular take based on experience: It's been my experience that a good chunk of accounting groups that run around with their hair on fire that the system is somehow not working... calls in someone with database or analysis skills, to discover something wasn't done as needed, or not configured and implemented. In this way, the Technical ERP whisperers out there who are not accountants but handle the "in depth analysis"..

  • journal 10 months ago

    I have all the in the works, including complex assemblies and reporting.

    I wish I had the $ to hire help.

    • j45 10 months ago

      If you might consider it, and YC wasn't a fit, I think something like tinyseed.com might be right up your alley.

      This is both mission based, as well as a sore need. I don't feel good right now, for example, having to consider which accounting system I'll be using next. Because it should mostly just be an API first, and I guess some screens activated where the API can't just run processes for me.

j45 10 months ago

Given how many accounting systems don’t use relational tables but use a relational db (like sap b1) and do joins manually, it would be a big step forward.

I have seen more than a few accountants dream about learning sql instead of their excel tai-chi.

I taught some to see sql as a sentence that was an instruction to join the columns they wanted.

Since everything is actually related tables.. it would be possible to just hand them something like metabase to start for all reporting since it can traverse and build up queues no problem.

The parent-child relationship I ran into as well as being an issue. It gets increasingly out of control and more complex that I wonder after a certain level of complexity whether sql is the best or sole way to go. I don’t know if this can be avoided at the cost of the user needing to know how to to do complex queries. Maybe there’s a way to simplify it with invoking stored procs somehow.

From this parent-child complexity side of things I explored graph databases for this and it seems to off some potential advantages, particularly for some complex use cases and queries. Keeping it postgres specific, PG can be extended with Hasura and then graphql is be available on the underlying schema. It really is something.

Beyond this, I’m spending more time with a knowledge graph databases outright.

If you haven’t had a chance, I highly suggest checking out TypeDB and a few demo videos. Chances are you will get to see some things you won’t be able to unsee and how it can help the Postgres design.

One of my use cases (non accounting) is sufficiently complex on the parent-child front that I have a basic interface between Postgres and TypeDB working to allow much easier querying and reporting via TypeQL.