Sunce_Solars: Sunce Solars: The ERP That Treats a Repair Like a State Machine
A solar-service system where tickets, job cards, SLAs, and handoffs are wired together to keep physical work auditable from pickup to closure.
- Sunce Solars is built around enforcing a repair lifecycle, not just storing service records.
- The ticket and job card split keeps customer-facing status separate from internal technical work.
- SLA timing, round-robin assignment, and transition validation turn the backend into a workflow governor.
- The data model and security middleware show a repo designed for accountability, not a throwaway demo.
The interesting thing about Sunce Solars is not that it is an ERP. It is that it treats a solar repair like a controlled sequence of responsibilities, deadlines, and handoffs. That is a much harder problem than CRUD, and the code knows it.
The repair workflow is the product
The center of gravity is the 10-stage lifecycle: ticket_created to closed. That sequence turns a messy physical job into something the software can govern, audit, and defend. The point is not just to know where a unit is. The point is to make skipping a step difficult.
That matters because physical service work fails in the gaps between systems. If intake, diagnosis, repair, dispatch, and closure live in separate spreadsheets or loosely enforced dashboards, accountability dissolves. Sunce Solars pulls those gaps into one governed path.
Tickets and job cards are not the same thing
The smartest modeling choice in the repo is the split between Ticket and JobCard. A Ticket is the customer-facing request, the visible status, and the SLA clock. A JobCard is the internal work log, where diagnosis, spares, testing, and unit condition live.
| Capability | Generic CRM or help desk | Sunce Solars |
|---|---|---|
| Workflow enforcement | Usually loose and manual | Strict status transitions with validation |
| SLA logic | Often external or optional | Calculated from ticket priority |
| Technical work detail | Usually shallow notes | Dedicated JobCard with diagnosis, spares, and testing |
| Assignment | Manual queue management | Round-robin distribution |
| Warranty handling | Often a field, not a process | AMC coverage built into the ticket flow |
| Security posture | Depends on the app | Sanitization, rate limiting, JWT, Helmet, bcrypt |
This split is more than tidy architecture. It mirrors the real world. Customers care about whether the repair is on track. Engineers care about what was found, what was replaced, and what condition the unit was in when it arrived.
Why the system refuses to skip steps
The transition logic is where the repo stops being a tracker and becomes a governor. The workflow does not accept arbitrary jumps. A ticket cannot leap from creation to dispatch without passing the states that create accountability along the way.
That logic creates two useful effects. First, it protects process integrity. Second, it makes the code legible to the team that has to operate it. People can see what is allowed, and they can see what would break the chain.
The assignment engine quietly prevents bottlenecks
Round-robin assignment is a small detail with big operational consequences. It stops the intake process from overloading one person while others sit idle. In a service business, that is not a nicety. It is throughput.
| Assignment model | Strength | Trade-off |
|---|---|---|
| Manual dispatch | Human judgment on every ticket | Slow and uneven under load |
| First-come queue | Easy to understand | Can create hot spots |
| Round-robin | Fair distribution across staff | Less room for ad hoc preference |
The interesting part is not that the algorithm is fancy. It is that it is boring, predictable, and hard to misuse. In operations software, that is often the right answer.
The data model separates identity from business reality
The repo also gets the model layer right. A User is not the same thing as a Customer. One is authentication. The other is the business relationship, with company details, service history, and AMC context attached.
That separation is what lets the system grow beyond authentication. It supports a service history that belongs to the customer account, not to whichever person happened to log in last. That is a better fit for real service operations.
Security is treated as baseline infrastructure
The backend does not treat security as an afterthought. It includes JWT auth, bcrypt, Helmet, rate limiting, and a custom sanitizer that strips dangerous keys before they reach MongoDB. That is the right posture for a system that handles service records and customer data.
None of this is flashy. That is the point. The project is trying to behave like software a business could trust, not a demo that only works on clean data and happy paths.
What this repo is really building
| Question | Answer in Sunce Solars |
|---|---|
| What is being tracked? | A repair process with physical responsibility attached |
| What is being enforced? | State progression, SLA timing, and assignment fairness |
| What is being separated? | Customer demand, internal technical work, and authentication |
| What is the business value? | Auditable service delivery for solar maintenance |
Sunce Solars is most compelling when you read it as operations software first and ERP second. It encodes discipline into the workflow itself, which is exactly what field service systems need when reality gets messy.