HITS - Haiku Integrated Treasury System
The name is debatable and I’m not good at coming up with stuff so feel free to talk about that, too.
(To begin: hello! This is my first post, but I’ve been enjoying Haiku and the community in Discord and IRC is amazing. Thanks to everyone who has helped me out so far. I’m not a developer myself, but I was told to post my ideas here to see if I get a “nibble”, so here I am. Thank you for the time anyone takes to read the following, as I find it to be a very needed thing to expand on the current “People” feature of the operating system. That said, let’s begin, shall we?)
Haiku has a lot of potential and the groundwork for a more robust method of reaching a larger audience in general, but computers have always been needed in the workplace. The entry cost of a good way of managing businesses is rather high, as computers keep getting more expensive. However, the low system requirements of Haiku allows cheaper systems to be made for the purposes of running useful software in these environments.
Business computer software has always been hit-or-miss, and many rely on spreadsheets or complicated standalone programs to get things accomplished. The open nature of contemporary software seems to miss a lot of what was passed over in the early days of home computing. Back then, it was all about the standalone software packages because no company had the time to both build an operating system and design integration of useful applications outside of settings and, well…more settings.
Many current and new businesses and non-profits require a way to manage their finances and build reports, but don’t have the means of training themselves or their volunteers on how to use software. On top of that, lots of software is moving to a “pay by the month” cloud model, which is not sustainable for many who are trying to do good in the world.
This is where HITS comes in strong. Giving people this integrated method of managing their business is beyond necessary for ease of use. Instead of having complicated software with dialog boxes and panes all over the place hiding the information required from the user, integrating this into the system would be far more approachable and easily understood by many simply by looking. At a glance, know you’re looking at a person or business profile, create reports that can be accessed for all people on the fly, and even create ODF spreadsheet files to share, or PDF files for printing out and filing away.
Below, this method will be explained with an outline. Please keep in mind that much of this is not set in stone, and input from others is desired. Please understand this is a suggestion itself as a feature request for Haiku, and not designed as a software package to be ported to other systems, as it is focused on taking advantage of system integration.
I. Entity – Used to create and manage people, businesses, and organizations as files on the system.
1. Person – as already integrated into the Haiku OS, currently referred to as “People”
A. The icon is as it currently is for a person file.
B. People can be added to a business or organization
C. People can pay a business or an organization.
2. Business – separate but equal in relation
A. The icon is a building of some sort in the same Haiku art style.
B. A business can pay and be paid.
C. Allows for taxation to be applied for credited payments (for example, when a Person Entity purchases one or more Product Entity).
3. Organization – For non-profits, they are not allowed to pay money to people in that organization, but can move money to others.
A. The icon could be the “three people” version of the icon or similar. (Hands shaking, for instance.)
B. This might be easier to just be run as a business but with a toggle to designate it as a non-profit, thereby making it where members of the non-profit are not allowed to receive payments, but payments can be made outside of it.
4. Product – a special Entity with a pricetag.
A. (This needs expanding upon, haven’t really thought it all the way through yet)
5. NOTES:
A. Entities, except Products, may have various payment information stored in their files as well, such as credit card, debit card, or other kinds of digital payments if desired.
B. Only one Entity may be selected as the owner’s mode of transfer, a “primary” Entity if you will. Personal users could use this for their own Person Entity, a business would select their own Business Entity, or an Organization Entity for a non-profit would use this.
C. In order for B to work correctly, this could be part of a setup process of some kind.
II. Reports – Used to consolidate reports for a People or Business file to show what they’ve paid, to who they’ve paid it, etc.
1. Can be edited individually by opening the Entity file.
2. The Report file can be generated by query to filter by desired dates.
A. This can then be applied to the various people or businesses
3. Any Report is basically a spreadsheet with the queried information.
A. This can be exported as an ODF or PDF when the query is made against an Entity.
III. System Integration.
1. First and foremost, this will require either the operating system or the files themselves to be secured. No password is not an option for the safety of internet connected systems.
2. Right clicking an Entity should give context options.
A. Pay – when that Entity makes a payment to another Entity
a. This can expand in the context menu to show all other Entities in the system.
b. Clicking Pay directly will give a dialog to select the person by a filterable list.
c. Once the intended payee Entity is selected, another dialog will ask how much to pay to that Entity along with a reason for clarification of payment.
B. Report – when the user wants to generate a report for that Entity
a. This can expand in the context menu to show all Report types the user has made.
b. You can click Report directly to get a dialog of the type of Report file to generate based on the Report files created by the user.
c. If a Report file isn’t there, the user should be allowed to generate any type of report query on the fly without saving a Report file.
d. After a Report type is selected, the user can then choose to export it as a PDF or ODF file for sharing or printing.
C. Receipt – when one entity has a need to issue a receipt to another entity.
a. This is mainly to be used for a non-Product entity issuing a receipt for one or more Product Entity. There is no expandable context for this menu.
b. When clicked, the user can add various Product entities to a list as needed.
1. Receipts are not an Entity. It will be its own dialog.
2. The user must select the default Business, Person, or Organization for issuing receipts. It cannot be selected, it must be determined by the system as the key business that system is being run for.
3. Only one non-Product Entity may be used to issue receipts. This is to protect the person operating the computer from potential fraud.
c. (POSSIBLY a way of integrating with external card-processors like Square or similar payment hardware. This is a preferred method but not necessary.)
When payments are made from one Entity to another, that information is stored along with that Entity’s file. In this way, backing up the Entity directory (which would at this point have previously been called “People”) will be all that is required to save the database.
There is also more integration that could be worked on for the future, such as using a more robust web-server with a default method of selling Product Entities, where users can create their own accounts which are then stored in their own “Person” Entity file. This might be a bit ambitious but it could also be a great way for small businesses to set up websites for their products. This isn’t something I’ve thought too deeply on at this point, but getting a database prepped for such a thing is a great way to tee up this future concept.
An Organization doesn’t have to be a non-profit, too. Religious organizations for example, though some might pay taxes, usually won’t be selling products. This is why the ability for a user of the system to create their own Person called “John Doe” instead of having John Doe create an account online. The treasurer of that organization could then manually input how much John has donated to the organization, again as opposed to John going online and doing it himself. There is no need for a non-profit to be online, except if they are accepting donations. Anonymous could be a default Person Entity for the sake of many organizations who get anonymous donations and aren’t aware of where it came from.
Other things to keep in mind are this: if there is eventually a website for people to create their Person Entity on, a method should exist for the user to consolidate an already existing Entity with the one created online, so reports can be created on their own time with information from before the online account was created as part of the user’s information.
Thank you to anyone who took the time to read this. Again I would like to reiterate that none of this is etched into a stone tablet and is very much open to be changed and discussed until a fully fledged concept is in view and a reasonable target to aim at is reached. Now if you’d excuse me, I’m going to hit “Create Topic” only to find I messed up somewhere in this message to my embarrassment. 
. But we can always dream… 