Project Overview: Asset Management System
This document provides a comprehensive overview of a custom Asset Management System as discussed. The system is a PHP web application (using SQLite for storage) that helps track assets, their financial details (installments and expenses), associated requirements, and related bank accounts. The interface is built with a responsive Bootstrap layout, ensuring usability on various devices. Below, we outline the full navigation menu, project file structure, details of each page, and the workflows for each type of data entry (asset, installment, expense, requirement).
Navigation Structure (Full Menu List)
Assets – Main section listing all assets in the system. This links to:
Asset List: Page showing a table of all assets with key info (e.g., name, status, cost, outstanding balance). From here, each asset can be selected to view its details.
Asset Profile: Detailed page for a specific asset (accessed by clicking an asset in the list). This is not a direct menu item but is part of the Assets section.
Requirements – Page listing all requirements across assets. Users can review what each asset needs (with status indicating incomplete, partial, or completed) and jump to related asset profiles or add new requirements.
Bank Accounts – Page listing all bank accounts associated with the system. Shows each account’s details (e.g., bank name or type, account number, and possibly current balance). Used to manage and reference funding sources for asset payments.
Data Entry – A dedicated page (or modal) for adding or editing data. It features a tabbed interface to input new Assets, Installments, Expenses, or Requirements. This page can be reached via shortcuts on other pages (for example, an "Add Asset" button on Asset List opens the Data Entry form for a new asset).
Every main page provides quick links to relevant entry forms. For example, the Asset List has an "Add New Asset" button, and an Asset Profile page has buttons to add an installment, expense, or requirement for that asset. This ensures a smooth navigation flow, as users can jump directly to the Data Entry interface from wherever they are.
Project File Structure (Expected Files)
Core PHP Pages:
index.php – (Optional landing or redirect) Could redirect to Asset List or contain a simple dashboard overview.
asset_list.php – Lists all assets with summary info and links to each Asset Profile. Provides actions like View (open profile) and Add Asset.
asset_profile.php – Displays detailed information for a single asset (full financial summary, associated requirements, and linked bank account info). Also includes action buttons to add related records (like a new installment or expense for this asset).
requirement_list.php – Shows all requirements in the system (possibly filterable by asset or status). Allows marking requirements as completed or jumping to add an expense to fulfill a requirement.
accounts.php – Lists all bank accounts and their details. Provides a form or link to add/edit bank account information.
data_entry.php – Unified data entry page containing forms for all create/update operations. Uses a tabbed layout (or modals) to switch between Asset, Installment, Expense, and Requirement entry forms. Each form on this page handles both creation of new records and editing of existing records.
Include Files (Reusable Components):
header.php – Common header fragment included at the top of pages. Contains the navigation menu (Assets, Requirements, Bank Accounts, Data Entry), the Bootstrap CSS/JS links, and any global scripts or styles. Ensures a consistent navigation UI and responsive layout across pages.
footer.php – Common footer fragment for pages. Closes any HTML containers opened in header, includes footnotes or closing tags, and possibly includes closing body/html tags. Could also load any footer scripts.
config.php – Contains configuration settings, including database connection for SQLite (e.g., specifying the SQLite database file path) and any constants (like currency format, etc.).
db_functions.php (optional) – A library of database helper functions or classes for executing queries (for example, functions to initialize the database, run SELECT/INSERT queries for assets, etc.). This helps keep SQL code organized.
functions.php (optional) – General utility functions (e.g., for formatting dates, currency, or computing summary values) that might be used across multiple pages.
Database Setup & Persistence:
SQLite Database File – For example, assets_db.sqlite stored on the server (or in a database/ folder). This file holds all persistent data tables. The main tables might include Assets, Installments, Expenses, Requirements, and Accounts. Each table stores the fields relevant to that entity (outlined in page details below).
setup_database.php – A setup script to initialize the SQLite database schema. When run, it creates the necessary tables (and possibly some initial data). This script can be executed once during installation or development to prepare the database. It defines all table structures (e.g., creating tables for assets, requirements, etc., with appropriate columns and relations).
Optional: schema.sql – Instead of (or in addition to) the PHP setup script, a plain SQL file listing the CREATE TABLE statements. This could be referenced by setup_database.php or used for documentation of the database structure.
Front-End Assets and Other Files:
CSS Directory (/css/):
bootstrap.min.css (if using a local copy of Bootstrap, otherwise loaded via CDN in header).
styles.css or custom.css for any additional custom styling to tweak the layout or design.
JS Directory (/js/):
bootstrap.bundle.min.js (for Bootstrap’s JS components if not via CDN, includes modal/tab functionality).
app.js for any custom JavaScript (e.g., to handle form submissions via AJAX, validate inputs, or dynamic UI behavior like toggling between full vs partial installment fields).
Uploads Directory (/uploads/):
A folder to store uploaded files or images for assets if needed. For example, if each asset can have a photo or if documents (receipts, contracts) are attached, they would be saved here. (This is optional and depends on whether file uploads are a feature – it’s included in the structure for completeness.)
Images Directory (/images/):
Any static images used by the UI (like a logo, icons if not using an icon library, etc.). Often, Bootstrap provides icons via fonts or SVG, but a directory can hold any custom images.
All PHP pages are organized to use the include files for common layout, ensuring the Bootstrap-based responsive design is consistently applied. The file structure separates concerns: content pages vs. shared layout vs. scripts vs. assets, which makes the project maintainable and scalable.
Individual Page Information
Below is a breakdown of each key page in the application, including its purpose, the data it displays or allows editing, and the actions available to the user on that page.
Asset List Page
Purpose: This page is the main dashboard of assets. It provides a quick overview of all assets being managed.
Data Displayed: A table or grid of assets with basic details. For each asset, it might show columns such as Name/Title, Category/Type (if applicable), Current Status (e.g. Active, Fully Paid, etc.), Total Cost or Value, Amount Paid So Far, and Outstanding Balance. This gives users a snapshot of each asset’s financial state. Each asset name is a link to its Asset Profile for more details.
User Actions: Users can click on an asset to view the full Asset Profile. There is also an Add Asset button (or menu item) on this page which takes the user to the Data Entry form (Asset tab) to create a new asset. Some implementations might include an inline edit or delete action for each asset (e.g., an Edit icon that also leads to the Data Entry page with that asset’s info loaded, and possibly a Delete icon to remove an asset). Additionally, the page might allow sorting or filtering of assets (for example, showing only active vs. completed assets), though those are optional enhancements.
(Navigation Note:) The header on this page (via header.php) contains the main menu links (Assets, Requirements, etc.), highlighting that “Assets” section is currently active. From here, the user can quickly navigate to other sections or add new data.
Asset Profile Page
Purpose: This page provides a detailed profile for a single asset. It consolidates all information related to that asset in one place, functioning as a dashboard for that specific asset.
Data Displayed: The Asset Profile is typically divided into sections for clarity:
Basic Details: Key identifying information about the asset – e.g., Asset Name, a description or address/location (if the asset is property or similar), category/type, and any custom fields (like in a real estate example, the size or specifications of the asset). It may also show an overall Status of the asset (for instance, “Active – Payments Ongoing” or “Completed – Fully Paid Off”).
Financial Summary: A comprehensive financial overview. This includes the Initial Amount or Purchase Price of the asset, the agreed Installment Amount (if the asset is financed), and a summary of payments:
Number of Installments Paid (count of full monthly payments made) and the total amount paid via installments.
Number of Installments Remaining (if any) or outstanding balance remaining on the asset’s purchase. If partial payments have been made, those are highlighted as well.
Partial Payments made: how many partial installment entries exist and the total sum of those partial payments (e.g., “Partial Payments: 3 (Total $3,000)” to indicate perhaps three half-payments made towards installments). This distinguishes them from full installments.
Total Paid to Date: The sum of all monies paid for the asset (installments + any additional expenses or partial payments).
Remaining Amount: If the asset was financed, this would be the amount still to be paid (initial price minus what’s paid so far). Once this hits zero, the asset might be marked as fully paid.
Expenses: A list of all expense entries associated with this asset (outside of installment payments). Each expense might show date, description, amount, and whether it was linked to a requirement. This helps track additional costs like maintenance, improvements, fees, etc. The sum of these expenses can be shown to see how much extra has been spent beyond the purchase price.
Requirements: A list of requirements tied to this asset. For each requirement, display its description, its current status (Incomplete, Partially Provided, or Completed), and maybe a note if it’s linked to an expense or fulfillment date. For example, a requirement could be “Install air conditioning unit – Status: Partially Provided (50%)”. If a requirement is completed, it might be highlighted or moved to a “Completed Requirements” sub-list. This section allows the asset owner to see what is needed to fully utilize or finalize the asset.
Bank Accounts: Banking information related to this asset. This could list which accounts are being used to fund the asset. For instance, it might show “City Bank ****0110 – Used for Installments” or simply the account names/numbers that have made payments. If multiple accounts contribute, all are listed (as seen in the conversation, e.g., multiple bank accounts like City Bank, AB Bank, or a mobile wallet were listed for an asset). This section helps the user know where the money is coming from or going. In some cases, it could also show the amount paid from each account, though that is an optional detail.
User Actions: The Asset Profile page is interactive. It typically provides buttons or links to add new related entries:
Add Installment: Shortcut that opens the Data Entry form to record a new installment payment for this asset. (This could be a button like “Add Payment”.)
Add Expense: Shortcut to add a new expense for this asset (e.g., “Log Expense” button).
Add Requirement: Shortcut to add a new requirement for the asset (perhaps a “New Requirement” button).
Edit Asset: Option to edit the asset’s basic information (brings up the Data Entry form in Asset edit mode).
If the asset is no longer needed, possibly a Delete Asset action (though deleting might be restricted if financial records exist, depending on design).
After any addition (installment, expense, etc.), the page refreshes to show the updated financial summary, reflecting the new data. This page thus serves as a one-stop view and management interface for all things related to the asset.
Requirement List Page
Purpose: The Requirement List provides a global view of all requirements across all assets, which is useful for tracking outstanding needs in one place. It ensures nothing falls through the cracks by giving a consolidated list of what is needed for various assets.
Data Displayed: Typically a table of requirements. Columns might include Requirement Description, Associated Asset (so you know which asset this requirement belongs to), Status (Incomplete, Partially Provided, Completed), and perhaps Last Update (like the date of the last expense or status change). You might also show an Expected Cost or Quantity if that was recorded when creating the requirement.
The list can be grouped or sorted by status or asset. For example, all Incomplete requirements could be highlighted or listed first. There may also be filters (e.g., show only incomplete requirements).
Each requirement entry might also note if it has any linked expense entries (e.g., “Partially Provided – $500 of $1000 spent” if such data is tracked).
User Actions: Users can manage requirements from this page:
Add Requirement: There could be an “Add Requirement” button to create a new requirement (user will select which asset it’s for in the form). This opens the Data Entry page (Requirement form).
Mark as Completed: For requirements that have been fulfilled (perhaps externally or through multiple expenses), the user might manually mark them complete. If the system is designed to auto-complete via expense entries, this action might not be needed except for cases where you want to force completion.
View Asset: Each requirement might have a link or button to view the associated Asset Profile (for more context). This helps the user jump directly to the relevant asset’s detail page.
Add Expense: There may also be a shortcut to add an expense for a requirement (to fulfill it). For instance, an incomplete requirement might have an “Add Expense to Fulfill” link, which opens the Expense form with that requirement pre-selected.
In summary, this page is a task-oriented view for ensuring all asset requirements are progressing. It complements the Asset Profile pages by focusing specifically on the requirements aspect.
Bank Accounts Page
Purpose: The Bank Accounts page lists all bank accounts or financial sources that are used in the system. This helps manage the sources of funds used for paying installments or expenses, especially if multiple accounts are involved.
Data Displayed: A simple list or table of accounts. Each entry could show Account Name (or Bank name), Account Number/Identifier (masked partially for security perhaps), and maybe a note or Balance. If the system tracks balances, the current balance or available funds in each account can be listed. (Balance would be updated manually or via integration; if not tracking balances, this field may be omitted or just left as informational).
For example, entries might look like: **City Bank Main Account – **0110 – Balance: $5,000, **AB Bank Savings – **4504 – Balance: $12,000, Bkash Wallet – 017XXXXXXXX – Balance: $500. These correspond to accounts that can be chosen when logging a payment or expense.
User Actions: On this page, an administrator or user can:
Add New Account: Provide details for a new bank account or funding source (via a form on Data Entry page or a simple inline form). The user might enter the bank name, account number, initial balance, etc.
Edit Account: Modify details of an existing account (for instance, update the name or balance). This could be done via the Data Entry page (if an Account tab exists or by reusing the form).
Delete Account: Remove an account (likely only allowed if it’s not used in any transaction records, to avoid orphaning references).
When adding or editing financial entries (installments/expenses) elsewhere in the app, these accounts are available for selection. This page ensures those account details remain up to date and provides an overview of all funding sources in one place.
Data Entry Page (Unified Form Interface)
Purpose: The Data Entry page is a centralized interface for creating new records or editing existing ones for all major data types: Assets, Installments, Expenses, and Requirements (and possibly Accounts). Having a single page for data entry simplifies navigation and ensures a consistent form style.
Structure & UI: The page uses a tabbed interface (Bootstrap tabs, for example) or a modal-switch approach to switch between different forms. Typically, you'll see a set of tabs like [Asset] [Installment] [Expense] [Requirement] (and possibly [Account] if needed). Clicking a tab shows the corresponding form fields. This way, one URL (data_entry.php) can handle all forms by showing the relevant tab based on user selection or a URL parameter (for example, data_entry.php?form=installment could open the Installment tab directly).
Each form section can also be implemented as a modal dialog launched from other pages for a smoother user experience. For instance, clicking "Add Expense" on Asset Profile could pop up a modal form (loaded via AJAX or included HTML) for expense entry. The system design allows either navigating to the Data Entry page or popping the form in a modal, thanks to this unified structure.
Forms (Data to Input):
Asset Form: Fields to add a new asset or edit an existing one. This typically includes:
Asset Name/Title
Description or details (could be multi-line, e.g., specifications or notes about the asset)
Category/Type (if the system categorizes assets – optional)
Initial Purchase Price (the cost or value of the asset)
Installment Plan Details: e.g., a checkbox or selector if this asset is financed. If yes, fields for Installment Amount (monthly payment amount) and perhaps Total Number of Installments or Financing Term. These allow the system to calculate remaining installments and detect full vs partial payments.
Associated Accounts: possibly allow selecting which bank account(s) will be used or is primary for this asset’s payments (optional, could also be just selected during each payment entry rather than at asset creation).
Other info: such as asset status (active, completed), or any responsible persons (like manager/engineer in the earlier example) – these fields depend on the context and can be extended as needed.
Installment Form: Fields to record an installment payment for an asset:
Select Asset: (if the form wasn’t opened from a specific asset context, a dropdown to choose which asset this payment applies to).
Payment Date: (defaults to current date or allows selection of the date the installment is paid).
Amount: (the amount paid). If the payment is a full monthly installment, this might auto-fill or validate against the expected installment amount for that asset. If it’s a partial payment, the user can enter a smaller amount.
Payment Type: A toggle or indicator for Full Month vs Partial. For instance, a checkbox “Mark as full installment” (if checked, the system knows this entry satisfies one whole installment period; if unchecked, it’s treated as a partial payment). This helps the logic in distinguishing payments.
Bank Account: Which account was used for this payment (choose from the accounts list).
(If needed, Notes: any remark about this payment).
When editing an installment record, the same form is used but populated with the existing data.
Expense Form: Fields to log an expense:
Select Asset: The asset that this expense pertains to.
Expense Date: Date of the expense.
Amount: How much was spent.
Description: A short description of the expense (e.g., “Purchased spare part” or “Maintenance fee”).
Link to Requirement: An optional dropdown to select a requirement that this expense fulfills. This dropdown is typically filtered to show incomplete or partially provided requirements for the chosen asset (so you can associate the expense directly with a requirement). If the expense is not related to a predefined requirement, this can be left blank.
Bank Account: Which account funded this expense.
(Optional Receipt Upload: If the system allows uploading a receipt image/file, the upload field would be here, with the file saved to uploads/.)
The expense form is also used for editing an expense entry.
Requirement Form: Fields to add a new requirement for an asset:
Select Asset: The asset that needs this requirement.
Requirement Description: A short text describing the needed item or task (e.g., “Air Conditioning Unit” or “Legal Compliance Certificate”).
Estimated Cost/Quantity: (Optional but useful) If known, an estimate of how much this requirement will cost or how many units are needed. For example, “Estimated Cost: $1000” or “Quantity Needed: 5 units”. This provides a basis to later judge partial fulfillment.
Status: The status will default to Incomplete when creating a new requirement. (On edit, this field could be changed, but typically status is managed by the system based on linked expenses or separate user action.)
The requirement form on edit mode allows updating the description or marking it complete if needed.
Account Form: (If integrated here) Fields to add/edit a bank account:
Account Name: e.g., “City Bank Checking” or “Bkash Wallet”.
Account Number/Details: e.g., the account number or wallet number (could be partially masked for display).
Initial/Current Balance: if tracking the balance in the system.
This form might be simpler and could alternatively appear on the Accounts page itself. If using Data Entry for accounts, it would be another tab.
User Actions (on Data Entry page):
Save/Submit: Each form has a submit button to save the data. On submit, the PHP code in data_entry.php will validate inputs and then either insert a new record into the SQLite database or update an existing record. After saving, it typically redirects the user back to an appropriate page:
For example, after adding an asset, redirect to Asset List or directly to the new asset’s Profile.
After adding an installment or expense, perhaps redirect back to that asset’s Profile (since the user was likely viewing the asset).
After adding a requirement, maybe redirect to either the asset’s Profile (to see it in context) or the Requirement list.
These redirect/logics ensure a smooth workflow.
Cancel: There might be a cancel/back link to return without saving (e.g., back to the previous page).
Form Switching: Users can switch tabs to a different form if they realize they need to enter something else. For instance, while on the Data Entry page, one can click the Requirement tab if they meant to add a requirement instead of an expense.
Thanks to the tabbed/modal design, the Data Entry page provides a streamlined experience for data management, without navigating through many separate pages for each type of entry. It ensures consistency in the look and feel of all forms.
Flow of Each Entry Type (Data Entry Workflows)
This section describes the typical workflows for creating and updating each type of entry in the system. It shows how a user would navigate and what happens at each step, integrating the logic (such as full vs partial payments and requirement status updates) into the flow.
Asset Creation & Editing Workflow
Initiate Asset Entry: The user starts by clicking the Add Asset button on the Asset List page (or in the menu). This opens the Data Entry page with the Asset form visible (or opens a modal form for asset entry).
Fill Asset Details: The user fills in the asset information – name, description, purchase price, etc., and (if the asset will be paid in installments) enters the installment amount and number of installments or selects a financing option. For example, they might input “Apartment #10, Price $75,000, Installment $2,000 per month for 10 months.”
Submit Form: On submitting, the system validates the inputs and creates a new asset record in the SQLite database (Assets table). It will set default values such as Outstanding Balance = Purchase Price initially, Installments Paid = 0, etc. The asset’s status is by default active/in-progress if there are outstanding payments.
Post-Submit Navigation: After saving, the user is redirected to an appropriate page:
Often, the Asset Profile of the new asset is shown, so the user can immediately see the asset’s details page (which would currently show that no installments have been paid yet, and all requirements are incomplete).
Alternatively, the app might return to the Asset List with a success message and highlight the newly added asset.
Editing an Asset: Later, if the user needs to update asset information (say to correct a name or change some detail), they would click an Edit action (pencil icon or similar) on the Asset Profile or Asset List. This again brings up the Data Entry page with the Asset form, but this time it’s populated with the asset’s current data for editing.
Modify and Save: The user changes the desired fields (for instance, update the asset’s status to “Completed” if they finished paying outside the system, or adjust the number of installments if renegotiated). On submitting the form, the system updates the existing asset record in the database.
Confirmation: After editing, the user is taken back to the Asset Profile (or list) to review the updated details. All pages that display asset information will reflect the changes (since they fetch from the updated database record).
Note: Deleting an asset would be a similar flow initiated by a “Delete” action, typically asking for confirmation and then removing the asset and all related records (installments, expenses, requirements) from the database. This must be done carefully to maintain data integrity (or deletions might be disabled if records exist, to be handled via business rules).
Installment Entry Workflow (Full Month vs Partial Payment)
Initiate Installment Entry: When an installment payment is due or made, the user navigates to record it. They can do this by clicking Add Installment on the Asset Profile page (for that specific asset). This opens the Data Entry form directly to the Installment tab, with the asset already selected. (Alternatively, the user could go to the Data Entry page from the menu and choose the Installment form, then select the asset manually.)
Choose Payment Type: The user enters the payment details:
If it’s a full monthly installment, the user might simply enter the expected installment amount (for example, $2,000) and perhaps tick a box or ensure “Full installment” is indicated. The system knows the standard installment amount from the asset record and can validate that the entered amount matches the expected amount (or is very close, accounting for rounding). The payment date is recorded (say the date they make that month’s payment).
If it’s a partial payment, the user enters the smaller amount (e.g., $1,000) and marks it as a partial payment (perhaps by unchecking a “full installment” box, or by the fact that the amount is less than the expected full installment). They still select the asset and date, and provide the amount actually paid.
The user also selects which Bank Account this payment is coming from (e.g., choosing “City Bank ****0110”).
Submit Installment: The user submits the form. The system then saves this payment in the Installments table (or possibly a Payments table) with a reference to the asset, date, amount, and a flag for full vs partial.
If the payment is marked as a full installment, the system will increment the count of installments paid for that asset by 1. It may also update an “Last Payment Month” field or similar to record which installment (or which month) was last paid.
If the payment is partial, the system will not increment the full installment count. Instead, it will record this partial amount and possibly update a running total of partial payments for the current installment cycle. For example, if an asset’s monthly installment is $2,000 and the user paid $1,000, the system knows there’s $1,000 still unpaid for that installment period. It might store that remaining amount or simply store the partial payment and rely on summing logic.
In both cases, the asset’s Outstanding Balance is reduced by the amount paid (so it decreases by $2,000 for a full payment, or by $1,000 for the partial in this example).
Handling Partial Payment Logic: The system checks if partial payments accumulate to a full installment:
If the user later records another partial payment of $1,000 for the same asset, the system can combine it with the previous $1,000 partial. Once the total partial payments reach $2,000 (the installment amount), the system can consider that as effectively one installment paid. It might then increment the Installments Paid count and reset the partial accumulator for that installment cycle.
In the records, the two $1,000 entries might either be marked as fulfilling one installment together or the second entry might trigger an update converting them. Different implementations exist: one way is to treat every payment the same and simply derive counts by summing amounts vs installment amount; another is to explicitly have an “installment number” field. For this overview, it’s enough that the logic ensures partial payments are tracked and when they sum up to a full installment, the asset’s status reflects that.
The Asset Profile’s financial summary will show something like “Installments Paid: 5” and “Partial Payments: 3 ($3,000)” to indicate maybe 5 full ones and some partial contributions. If one more partial payment of $1,000 is made, it could then change to “Installments Paid: 6” and “Partial Payments: 0 (fulfilled another installment)”.
Post-Submit Navigation: After saving the installment, the user is typically taken back to the Asset Profile page. There, they can immediately see the updated payment summary:
The Last Payment Month might update (e.g., if a full installment for March 2025 was just added, it might show Last Payment Month: March 2025).
If it was a partial payment, the profile might show an updated partial total and still indicate the installment for that month is not fully paid.
Outstanding balance decreases accordingly.
User Verification: The user can verify that the installment was recorded correctly. If there was a mistake, they could use an Edit action on that installment (perhaps via an “Edit” button next to the payment entry in the expense/instalment list on the profile) to correct the amount or details.
This flow allows flexible handling of payments. Full installment entries immediately count toward the asset’s progress, while partial entries ensure even smaller payments are tracked and later aggregated. The interface highlights these differences so the asset owner knows if they have any partially paid installments pending completion.
Expense Entry Workflow (Linking to Requirements and Updating Status)
Initiate Expense Entry: When an expense is incurred for an asset (outside the regular installment payments), the user records it by clicking Add Expense on the Asset Profile page or from the Requirements page (if the expense is to fulfill a requirement). This opens the Expense form on the Data Entry page, with the asset pre-selected (and possibly the requirement too, if triggered from a specific requirement).
Fill Expense Details: The user fills in the expense form:
Select the Asset (if not already set) that the expense relates to.
Enter the Date of the expense and the Amount spent.
Write a Description (e.g., “Bought spare parts for machinery” or “Legal fees for transfer”).
Link to Requirement: If this expense is intended to fulfill a requirement, the user chooses the specific requirement from a dropdown. For example, the asset might have a requirement “New Air Conditioning Unit” (Incomplete). The user selects this requirement to indicate the expense is for that item. If the expense isn’t directly tied to a requirement, this can be left blank.
Select the Bank Account used to pay this expense.
Submit Expense: The user submits the expense form. The application saves this data as a new record in the Expenses table, capturing asset, amount, date, description, and linked requirement (if any) along with the account.
The asset’s total spending is updated (this expense might add to some “Total Expenses” sum in the Asset Profile’s financial summary).
If the expense was linked to a requirement, the system will update the status of that requirement:
For a requirement that had been Incomplete, any expense against it typically moves it to Partially Provided (unless the expense completely satisfies it in one go).
If the expense amount (or item quantity) fully covers the requirement, the requirement can be marked Completed. For example, if the requirement was “Purchase generator (expected $5000)” and the user logs an expense of $5000 for a generator, the system can mark that requirement as Completed.
If the requirement needed multiple items or continuous spending, the first expense would mark it Partially Provided. The system might store how much of the requirement is fulfilled: e.g., “$300 out of $500 provided” or “3 of 5 units acquired” depending on the nature of the requirement. Subsequent expenses linked to the same requirement would accumulate. When the total meets the requirement’s goal (cost or quantity), the status flips to Completed.
The requirement’s record (in the Requirements table) is updated accordingly (status field changed, and possibly a field for amount provided so far or date completed).
If the requirement is completed, the system might also log the completion date or mark it in the requirement list for reference.
Post-Submit Navigation: After saving the expense:
If the expense was added from an Asset Profile context, the user is returned to that Asset Profile page. The page now shows the new expense in the expenses list. If it was linked to a requirement, the requirement’s status on that page will have updated (e.g., from Incomplete to Partially Provided or Completed).
If the expense was added from the Requirement List context (e.g., the user clicked “Add Expense” next to a requirement), the user might be directed back to the Requirement List page. There, they can see that the requirement’s status has changed (perhaps now “Partially Provided” with some indication of progress).
Verify and Continue: The user checks that the expense is listed correctly and that any linked requirement reflects the proper status. If another expense is needed for the same requirement (not fully fulfilled), the requirement will remain Partially Provided and the user can log additional expenses later following the same flow.
Alternate – Marking Completion without Expense: If a requirement is fulfilled without a direct monetary expense (for instance, an item was provided in-kind or by a different department), the user might update the requirement status manually. This could be done by editing the requirement on the Requirement List or Asset Profile (changing status to Completed) or clicking a “Mark as Completed” button. In that case, no expense entry is added – the system just updates the requirement status in the database. This is a separate path but results in the same final status update.
Through this flow, every expense is tracked, and if tied to a requirement, keeps the requirements up-to-date. The link between expenses and requirements ensures that financial expenditures directly contribute to meeting the asset’s needs, and provides transparency: one can look at a requirement and see what expenses were made to fulfill it.
Requirement Entry & Tracking Workflow
Initiate Requirement Entry: When the user identifies a new need for an asset, they add a requirement. This is done by clicking Add Requirement on the Asset Profile (to add a need for that asset) or via the Requirement List page (where they’ll choose the asset in the form). Either action opens the Requirement form on the Data Entry page.
Fill Requirement Details: The user enters details for the requirement:
Confirm/select the Asset that needs something.
Write the Requirement Description (e.g., “Secure storage cabinet” or “Completion certificate”).
Optionally, enter an Estimated Cost or Quantity. For instance, they might expect it will cost $500, or they need 3 units of something. (Even if the system doesn’t strictly require this, it’s useful for tracking partial fulfillment later.)
The Status will default to Incomplete (since this is a new requirement not yet fulfilled).
Submit Requirement: On submission, the system creates a new record in the Requirements table with status “Incomplete” and links it to the specified asset. It does not yet have any fulfillment associated with it.
The Asset Profile page for that asset will now list this requirement under an “Incomplete Requirements” section.
The global Requirement List will also show this new requirement as Incomplete.
Tracking Progress: Once a requirement is in the system, the user (or multiple users) can work towards fulfilling it. The tracking happens via:
Expense Entries: As described in the expense workflow, whenever an expense is logged against this requirement, the system updates the requirement’s status. Suppose the requirement was “Secure storage cabinet ($500 estimated)”. If an expense of $300 is logged for it (maybe a down payment or purchase of some materials), the requirement might update to Partially Provided and note that $300 of $500 has been covered.
The requirement status visible on both the Asset Profile and Requirement List will change to Partially Provided. The Requirement List might show a progress like “60%” or “$300/$500” if such a field is maintained.
If a second expense of $200 is later logged for the same requirement, the system will now mark the requirement as Completed, since the total $500 has been spent (meeting the estimated need). The status field in the database updates to Completed, and possibly a completion date is recorded.
If the requirement was something not easily quantified by money (say “Obtain permit from city”), the user might not attach an expense but once the permit is obtained, they could edit the requirement and mark it Completed manually.
Status Transitions: The typical lifecycle of a requirement’s status is:
Incomplete: No action taken yet or no resources provided. All new requirements start here.
Partially Provided: Some resources or money have been provided, but the requirement isn’t fully satisfied. This happens automatically when an expense is linked to the requirement but is not sufficient to complete it, or when only part of the required items are delivered. For example, if 3 out of 5 units have been acquired, status remains Partially Provided.
Completed: The requirement has been fully met. This could occur automatically when the sum of linked expenses meets or exceeds the estimated cost, or when a user manually marks it complete (for non-monetary requirements or after the final expense). Once completed, no further action is needed on that requirement, though the history (what was spent, when it was completed) remains for reference.
Review and Management: Users regularly review the Requirement List to monitor these statuses. They might prioritize Incomplete or Partially Provided requirements:
For any Incomplete requirement, decide if an expense needs to be made or some action taken. They can click “Add Expense” straight from that requirement row when ready to spend.
For Partially Provided requirements, they can see what more is needed (how much money or quantity remains). They will continue the fulfillment process, adding more expenses or taking actions until it’s Completed.
Completed requirements might be filtered out or shown in a separate section so the focus remains on what’s still pending.
Editing or Deleting Requirements: If a requirement was added in error or needs modification, the user can edit it (e.g., change the description or adjust the estimated cost if they got a new quote). Editing is done via the same Requirement form on the Data Entry page, loaded with existing data. Deleting a requirement might be allowed only if it has no expenses linked (or else the expenses should probably be deleted or unlinked first to maintain data consistency).
Through this workflow, the system ensures that for each asset, all requirements are documented and their fulfillment status is tracked in real time. This provides visibility into what tasks or purchases are outstanding for each asset and helps in planning and budgeting. By linking requirements with expenses, the system also provides accountability (you can see exactly what was spent to meet each requirement).
Design & Technology Summary: Throughout all these pages and workflows, the system uses a responsive web design (leveraging Bootstrap’s grid and components) to make the interface accessible on desktops, tablets, or phones. The navigation menu adapts to mobile (collapsing into a toggle menu), tables scroll or reflow as needed, and forms stack neatly on smaller screens. The backend PHP code uses SQLite for persistent data storage, meaning all entered data (assets, transactions, etc.) is saved in a lightweight database file on the server. This setup makes the application easy to deploy without a separate DB server, yet robust enough to handle the needed queries (with proper indices on foreign keys like asset_id for performance). In conclusion, this project overview serves as a blueprint for developing the Asset Management System. It covers the navigation structure, file organization, functionalities of each page, and the end-to-end data flows for managing assets, payments, expenses, and requirements. Following this plan will guide the implementation from start to finish, ensuring that all features discussed are accounted for in the development process.