story: biz tool #210
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/home#210
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Deliverables
Deliverables
Deliver a working organization business tool where the user can select a context, with each context representing a company or organization. Inside that context, the tool must manage the full company workflow: CRM/contacts, tasks, projects, stories, shareholders, contracts, employees, finance-related records, and all other business functions already present in the app.
The deliverable is not a new app-store or modular system. The goal is to make the existing integrated business tool usable, connected, and consistent for one organization at a time, with proper cross-linking between records, clean naming, readable data, formatted amounts, and working create/edit/save flows.
Requirements
Updated Specs / Feedback Notes
Context
The first business app is intended for internal company use first.
It is one integrated tool for now, not a set of perfectly separated apps.
The tool should support:
Later we can split things up if needed, but today the goal is simple:
There are currently two business tools.
The focus should be on the non-Dioxus business tool, because that version already had most of the features before.
Most of the existing comments are okay.
The comments below clarify what needs to change.
General
1. Business suite structure
The current structure is acceptable for now.
We are not trying to decide today whether every part should become a separate app.
For now, we want one business tool that brings together:
The main requirement is that the tool works cleanly and consistently.
2. No app store discussion for now
Do not focus on Store or app-store logic today.
We do not need to solve whether CRM, HR, Finance, Contracts, or Tasks should be optional installable modules.
That can come later.
For now:
Naming Rules
1. Use Contacts, not People
The correct term is:
Do not rename this to People.
A contact is the person or party we can interact with.
Use Contacts consistently across:
Example:
Current:
Should become:
2. Remove “Persons”
The term Persons should not be used.
Replace:
This applies everywhere.
3. Contact is not the same as Interaction
A contact is not an interaction.
A contact is a person or reachable business relationship.
An interaction is an activity or touchpoint with a contact.
Examples of contacts:
Examples of interactions:
So the model should be:
4. Keep Contacts and Interactions separate
We should not replace Contacts with Interactions.
They are different things.
A contact can have many interactions.
Example:
Contact:
Interactions:
BIZ
1. Save error must be fixed
Current issue:
Requirement:
This must be fixed.
The app cannot be tested or used properly until save actions work.
This is a technical routing/socket issue and must be maintained and corrected.
2. Use Contacts
Do not rename Contacts to People or Interactions.
Requirement:
Use:
A contact is the person or party we can interact with.
3. Remove Persons
Current issue:
Requirement:
Replace:
Example:
Current:
Should become:
4. Interactions should only be activity logs
If there is a section with fields like:
Then that section can be called:
But it must be linked to a Contact.
An interaction should not replace the Contact record.
Business / CRM
1. Focus on the non-Dioxus version
Requirement:
Focus implementation and fixes on the non-Dioxus business tool.
Reason:
This version already had most of the features in the past and is the better base for now.
2. Use Contacts everywhere
Requirement:
Use Contacts as the main term for people/person records.
Do not use:
Use:
3. Contact and company relationship
A contact can be linked to one or more companies.
Example:
Contact:
Linked company:
Role:
The company page should show its linked contacts.
The contact page should show linked companies.
4. Contact and interaction relationship
A contact can have multiple interactions.
Example:
Contact:
Linked interactions:
The contact detail page should show these interactions.
The interaction detail page should link back to the contact.
5. Replace internal SIDs with readable names
Current issue:
Requirement:
Do not show raw internal SIDs as the main display value.
Show the readable contact name or title, linked to the related record.
Example:
Instead of:
Show:
If the SID is useful, it can still be shown as secondary technical information.
Example:
6. SID display rules
SIDs still need to be maintained.
Requirement:
Every page should show related records with:
If a name or title is too long, it should be shortened automatically so it fits cleanly in the grid.
Example:
7. Empty values
Current issue:
Requirement:
Empty values should show:
Never show
0for missing values.This applies to:
8. Amount and currency formatting
Current issue:
Requirement:
All amount fields must be formatted clearly.
Examples:
10000000→€10,000,000250000→€250,0001500→€1,500Currency must always be shown.
Currency codes must be uppercase:
Never show lowercase currency such as
eur.9. Compact amount formatting
Where space is limited, compact formatting may be used.
Examples:
€10,000,000→€10M€250,000→€250KRequirement:
Use full formatting in detail views.
Use compact formatting in grids and cards when space is limited.
10. Currency selector
The Business tool should include a currency display selector.
This allows the user to view amounts in the currency relevant to them.
The selected currency should always be displayed clearly.
Examples:
€10,000,000$10,000,000£10,000,000HR
1. HR must not stay read-only
Current issue:
Requirement:
HR needs full CRUD before it can be considered usable.
Required actions:
2. HR must link to Contacts
Current issue:
Requirement:
HR records must link to the shared Contacts data.
An employee, contractor, advisor, or partner should also be a Contact.
Do not create a disconnected HR person database.
Example HR record:
Cross-Linking Requirements
This is one of the most important missing parts.
The app should not feel like separate disconnected databases.
Required links
Company page should show:
Contact page should show:
Interaction page should show:
Deal page should show:
Contract page should show:
Finance page should show:
Task/project page should show:
Business Overview Page
The Business overview page should briefly explain what each area is for.
Example:
Contacts
People and business relationships we interact with.
Companies
Organizations linked to contacts, deals, contracts, HR, and finance.
Interactions
Calls, emails, meetings, notes, and follow-ups linked to contacts and companies.
Deals
Opportunities, investment discussions, sales opportunities, or commercial tracks.
Contracts
Agreements and legal/commercial documents linked to contacts and companies.
Finance
Amounts, invoices, payments, budgets, and financial records.
HR
Employees, contractors, advisors, and team-related records linked to contacts.
Tasks / Projects
Execution layer for work linked to business records.
Updated Suggestions
Must fix now
–for empty dates or empty optional values.Should do soon
Not needed now
For now, we first make the business tool work well as one integrated app.
@casper-stevens
Can you check this please?
Maybe your work already takes this into account. Just the part [BIZ]
Thanks
[Business] Testing feedbackto story: biz tool@casper-stevens
Regarding "3. Contact and company relationship"
This is how I believe it should look/be implemented on the UI
Contact record (top level fields)
On the contact page - linked companies table
A section called "Companies" listing all companies this person is linked to:
Role is specific to that company relationship. Status can be Active or Former so we can track past connections without deleting them.
On the company page - linked contacts table
A section called "People" listing all contacts linked to this company:
Editing
The goal is to always understand a contact's full picture at a glance: who they are, where they work or have worked, and in what capacity.