The Samaneh Modiriat Hooshmand Aramestan is an integrated platform for recording and following up plots, graves, applicants and cemetery services, moving the day-to-day work of the operator from scattered ledgers into a spatial database. It is implemented with Next.js on the presentation layer, Prisma for data access and PostgreSQL as the database, and it binds the record of each grave to its position on the map. The main goal is to unify records, reduce duplicate work and give managers a clear picture of plot capacity and occupancy. Financial and service records live in the same environment, so the file of every applicant stays complete and the dashboards and reports are built on that same data.
The problem this system solves
In cemeteries the data on graves, applicants and services is usually kept in several separate registers and files; this fragmentation makes finding a grave or tracking the state of a request time-consuming and leaves the real capacity of the plots out of easy reach.
By merging the spatial file with the service records, the system allows fast search by grave number, applicant name, plot and date range, and prevents the same grave or applicant from being entered twice.
Events that were once recorded only on paper are now stored as queryable, reportable records, so the history of each plot can be reconstructed over time.
Users, roles and daily workflow
Users are grouped into several work roles so that each group reaches only part of the data. The intake officer registers the applicant record and the service request, the map officer keeps the spatial state of the graves up to date, and the manager views aggregate reports and occupancy status.
Roles are defined inside the system, and each user’s access is controlled by the role assigned to them.
- Intake officer, who records applicant data and service requests.
- Spatial officer, who maintains the plot map and grave positions.
- Finance officer, who handles contracts, tariffs and account follow-up.
- Manager, who views the dashboard, reports and overall control.
Plots, graves and service requests
The base unit of data is the plot and the grave: each grave is a unique record with its own number, spatial position, occupancy status and related service file.
A service request is a record that holds the service the applicant asked for together with its items, so it is clear which service was recorded, when, and for which grave.
The state of each request is tracked in the system, so the officer can see the current stage and the final result without going back to the register.
The plot structure makes it possible to keep the spatial information of each row of graves, and plot boundaries are visible on the map.
Contracts, annual tariffs and catering
Every service delivered is recorded as a contract; the contract is linked to the applicant and to the relevant grave and forms the basis for following up the obligations of both parties.
Tariffs are stored per year so that service costs are computed with the tariff of the matching year, while the record of earlier tariffs is preserved.
Catering items and products are also recorded in the same environment and attached to the contract or service request, so the account stays consistent.
- Recording the contract and its link to the applicant and grave.
- Holding annual tariffs and using the tariff of the matching year.
- Entering catering items and products in the service file.
Data, maps and KML import
The spatial layer of plots and graves is held in the PostgreSQL database and displayed on the map through the Next.js interface. Each grave’s position is bound to its descriptive record so that search and analysis by location are possible.
The system supports importing data from KML files; boundaries and positions prepared earlier in mapping tools are transferred into the system without being redrawn.
Data access goes through Prisma and defined models, so queries remain uniform and maintainable.
Deployment, integration and access control
The architecture is based on Next.js, Prisma and PostgreSQL and can be deployed on the operator’s own server, keeping the data under the organisation’s control.
Integration with other tools and systems is possible through the same data layer and programming interfaces; KML import is one of the routes for bringing data in from mapping tools.
Access control is enforced by user role, and each user sees and edits only the part of the system entrusted to them.
Rollout and delivery
Rollout begins with defining the plot boundaries and designing the data structure; the map and spatial layers are then loaded and the grave records are linked to their positions.
In the next step the current tariffs and the list of catering products are entered and the user roles are defined for the officers.
Once the initial data is loaded, operation starts and the grave and service information is updated at successive intervals.
Summary
The Samaneh Modiriat Hooshmand Aramestan turns scattered grave and service information into a single database and map and simplifies the follow-up of requests, contracts and tariffs.
Its implementation on Next.js, Prisma and PostgreSQL makes the system predictable to maintain and extend, and KML import support eases the migration of existing spatial data.
With clearly defined roles and access control, sensitive file data stays with authorised users only, and management reports are available for decision-making.