InfraMat: A Web-Based Construction Material Management System for GB Construction

1Introduction

A construction material supplier does not deal with only one type of record. A single customer order may involve checking material availability, arranging production, selecting a vehicle, recording a delivery and updating the payment details. Each step depends on information from another part of the business.

For a company such as GB Construction, keeping these records separate can create problems. A stock register may show one quantity while a production record contains another. A manager may have to check with a driver to find out whether a delivery has been completed. Payment information may also be difficult to match with the correct order if it is maintained separately.

InfraMat was developed to address this record-management problem. It brings the main activities of the business into one web application. The system covers construction materials, suppliers, customers, orders, production, vehicles, delivery trips, payments and diesel expenses.

The application is divided into four user roles: Admin, Manager, Driver and Customer. Each role is intended for a different type of user. This makes it possible to organize access according to the work being performed instead of giving every user the same functions.

The project focuses on connecting everyday business operations. It does not attempt to replace specialized production-planning or vehicle-routing software. Its purpose is to provide a common place to maintain and review the information used by the business.

2Problem statement

The main issue addressed by InfraMat is the difficulty of managing connected business activities through scattered records.

Consider a customer who places an order for construction material. The order has to be recorded, its material requirement has to be checked, and production may be needed before dispatch. Once the material is ready, a vehicle and driver have to be assigned. After delivery, the payment record must also be updated.

If every department maintains its own information, staff may have to enter the same details more than once or contact other departments to confirm the status of an activity. This makes it harder to follow an order from the time it is received until its delivery and payment are completed.

The project addresses the following problems:

• Stock quantities can become difficult to maintain when receipts, consumption and dispatch are recorded separately.
• Customer orders may be difficult to follow across production and delivery.
• Supplier, customer, vehicle and driver information may be spread across different records.
• Material consumption during production needs to be connected with inventory.
• Delivery details need to be linked to the relevant order and vehicle.
• Payment and diesel expenses need to be recorded and reviewed separately.

InfraMat brings these records into one application so that related information can be maintained through connected modules.

3Objectives and scope

3.1Objectives

The objectives of the project are:

• To maintain records of construction materials and available quantities.
• To store supplier and customer information.
• To record customer orders and their delivery requirements.
• To maintain production records and material consumption details.
• To manage vehicle and driver information.
• To record vehicle capacity and availability.
• To maintain delivery trip information and status.
• To record customer payments and outstanding amounts.
• To maintain diesel consumption and vehicle expenses.
• To provide separate access for Admin, Manager, Driver and Customer.

3.2Scope

The current project covers the main record-management activities of GB Construction. These include inventory, suppliers, customers, orders, production, vehicles, deliveries, payments and diesel expenses.

The system is intended to make these activities easier to manage by keeping their information within one application. Features such as GPS-based live tracking, a dedicated mobile application, automatic low-stock notifications, online payment integration and advanced forecasting are possible future additions. They are not treated as existing features in this paper.

4Review of related work

Digital systems are increasingly being used to manage material procurement, inventory and logistics in the construction industry. The studies reviewed below provide background for the problems that InfraMat addresses.

Carrillo, Mendoza Reategui and Díaz Ruiz [1] discuss material planning, inventory control and warehouse layout in a construction SME. Their work is relevant to InfraMat because the availability of correct material information is important when planning construction activities. Their study also discusses IoT-based inventory control, which is outside the current scope of InfraMat.

Parisi, Donyavi and Flanagan [2] examine digital transformation in construction SMEs, particularly in material procurement. Their work looks at the difficulties of manual processes and the use of digital tools to improve procurement activities. InfraMat follows a practical approach to this problem by maintaining procurement-related and operational records in one application.

Mohd [3] presents a digital system for material procurement and inventory management in construction projects. The study is closely related to the inventory and order modules of InfraMat. The project described in this paper also includes production, vehicle, delivery and payment records.

Other research focuses on ready-mixed concrete production and distribution. Guan et al. [4] study an improved ant colony optimization algorithm for automated RMC distribution. Tibaldo, Montagna and Fumero [5] present a mathematical model for managing RMC production and distribution. Buhaievskyi and Petrenko [6] also discuss planning and optimization in RMC production and logistics.

These studies deal with planning problems that can involve several constraints, such as production capacity and delivery requirements. InfraMat has a narrower purpose. It maintains the records required for regular business operations rather than calculating optimized production schedules or delivery routes.

Shah and Shah [7] examine ERP-integrated inventory control in construction. Zhang [8] studies the role of data-based coordination in the construction supply chain. Both areas are related to the need for consistent information across different business activities.

Mailana and Ayumi [9] describe an inventory management application for a construction service company. Aritonang, Terttiaavini and Ariati [10] discuss a web-based logistics information system for building materials. These studies show the practical use of information systems for construction inventory and logistics.

The reviewed work covers different parts of construction management. Some studies focus on procurement and inventory, while others deal with production planning, distribution or supply-chain coordination. InfraMat brings several of these day-to-day record-management activities together in one application for GB Construction.

5Research gap

The studies discussed above address important problems in construction management, but their main areas of focus differ.

Research on inventory and procurement deals with material availability and the movement of goods. Work on RMC planning looks at production and distribution decisions. Other studies discuss ERP systems, supply-chain information and logistics applications.

InfraMat focuses on the connection between these activities at the application level. Its modules cover material stock, suppliers, customers, orders, production, vehicles, delivery trips, payments and diesel expenses.

The gap addressed by this project is the need for a shared operational record system that connects these activities for GB Construction. The project does not claim that no existing commercial software offers similar functions. Its contribution is the development of an application around the business activities included in this project.

6System architecture and technologies

InfraMat follows a web application structure in which the frontend, backend and database have separate responsibilities.

6.1Frontend

HTML, CSS and JavaScript are used to build the user interface. Tailwind CSS is used for styling. Users interact with the application through its screens and provide the information required for different operations.

6.2Backend

Node.js and Express.js are used on the server side. The backend receives application requests, processes the required operations and communicates with the database.

6.3Database

SQLite is used during local development and testing. MySQL is used for the final deployment. The database stores the information used by the different modules, including material, supplier, customer, order, production, vehicle, delivery and payment records.

6.4Application flow

A user first accesses the application through the frontend. The request is sent to the backend, where the required operation is processed. The backend then reads or updates the relevant database records and returns the result to the frontend.

7User roles

InfraMat has four main user roles (Table 1).

Role	Purpose
Admin	Handles user management and overall system administration.
Manager	Handles business activities such as inventory, orders and production.
Driver	Uses vehicle and delivery-related information.
Customer	Accesses customer and order-related information.

The purpose of separating these roles is to keep the application organized around the responsibilities of its users. The exact actions permitted to each role depend on the access rules implemented in the application.

8System modules

The modules in InfraMat handle different types of information. Their records are connected because an activity in one part of the business can affect another.

8.1Inventory management

Inventory management deals with the quantities of materials available in the business. It records material information and stock changes.

When new material is received, the quantity is added to the stock balance. When material is consumed during production or dispatched, the quantity is reduced. Keeping these transactions connected makes it easier to review the current stock position.

8.2Supplier management

The supplier module stores supplier information. These records can be referred to when managing materials and supplier-related activities. Maintaining the details together avoids the need to search through separate records whenever supplier information is required.

8.3Customer management

Customer records are used when handling orders and related transactions. Keeping customer information in one place also helps connect an order with the correct customer.

8.4Order management

The order module records customer requirements. An order may contain information such as the customer, requested material or product, quantity and delivery details.

The order record is important because other activities may depend on it. Production, delivery and payment information can be reviewed in relation to the corresponding order.

8.5Production management

Production management records production activities and the materials used. This is important because production affects inventory.

For example, when a production activity consumes raw materials, the quantities used need to be recorded. The corresponding inventory balances can then be updated according to the recorded consumption.

8.6Vehicle management

The vehicle module stores vehicle details, driver information, carrying capacity and availability. These details help the manager check whether a vehicle can be considered for a particular delivery.

8.7Delivery management

The delivery module maintains trip information and delivery status. A delivery record can be related to an order, vehicle and driver. This makes it easier to review which vehicle and driver are associated with a particular trip.

8.8Payment management

The payment module maintains payment information related to customer transactions. The recorded payments can be compared with the order amount to calculate the outstanding balance.

8.9Diesel expense management

Diesel management records fuel consumption and related vehicle expenses. These entries can be used to review fuel-related costs and maintain vehicle expense information.

9Workflow of the system

The modules are most useful when their records are considered together.

The process begins when a customer requirement is recorded as an order. The manager reviews the order details and checks the material requirement. If production is needed, the relevant production activity is recorded along with the materials consumed.

Once the required material is ready, the delivery can be arranged. The manager checks the available vehicles and their carrying capacity before selecting a suitable vehicle. The delivery trip is then recorded with the relevant order and driver information.

After the transaction progresses, the payment details are maintained against the customer or order. Diesel expenses are recorded separately as vehicle-related expenses.

This workflow shows how an order can involve several modules. Instead of maintaining unrelated entries, InfraMat provides a common application in which the records can be connected.

10Algorithms and business rules

The procedures used in InfraMat are based on ordinary business conditions and calculations. They are rule-based operations rather than artificial intelligence or advanced optimization algorithms.

10.1Stock calculation

The stock balance changes whenever material is received, consumed or dispatched.

The calculation is:

Where:

• S_u = updated stock
• S₀ = opening stock
• R = received quantity
• C = quantity consumed during production
• D = dispatched quantity

Procedure:

1. 1. Read the opening stock.
2. 2. Add the quantity received.
3. 3. Subtract the material consumed during production.
4. 4. Subtract the quantity dispatched.
5. 5. Check the calculated balance.
6. 6. Save the updated stock if the transaction is valid.

A negative stock balance should be treated as an invalid condition or flagged for review.

10.2Order processing

Order processing begins when customer details and order requirements are entered.

The basic procedure is:

1. 1. Receive the customer and order details.
2. 2. Check whether the required information has been entered.
3. 3. Validate the requested quantity.
4. 4. Create the order record.
5. 5. Send the order through the required review or approval process.
6. 6. Check the related stock or production requirement.
7. 7. Update the order status as the process continues.

The order status should reflect the actual stage reached by the transaction.

10.3Production consumption

Production uses materials that are recorded in inventory. The consumption procedure checks the available quantities before recording the material usage.

1. 1. Select the production activity.
2. 2. Identify the materials required.
3. 3. Read their available stock quantities.
4. 4. Compare available quantities with the required quantities.
5. 5. If a required quantity is not available, flag the entry for review.
6. 6. If the quantities are sufficient, record the consumption.
7. 7. Update the relevant stock balances.

10.4Vehicle eligibility

A vehicle should meet the delivery requirement before it is selected.

The two basic conditions are:

• The vehicle must be available.
• Its carrying capacity must be equal to or greater than the required load.

The procedure checks these conditions and displays the vehicles that meet them. The final selection can then be made by the responsible user.

This is a basic eligibility check. It does not calculate the shortest route or the lowest delivery cost.

10.5Payment balance

The outstanding payment is calculated by subtracting the payments received from the order amount.

The calculation uses the payment entries linked to the relevant order.

11Sample calculations and system output

The following examples explain how the business rules work. The values are sample values and are not actual records from GB Construction.

11.1Inventory example

Assume that the opening stock of a material is 500 units. During the period, 100 units are received, 160 units are used in production and 20 units are dispatched.

The remaining stock is 420 units.

If another production activity requires 450 units, the available quantity is short by 30 units. The system should not treat the entire requirement as available.

11.2Vehicle selection example

Suppose a delivery requires a vehicle with a capacity of 8 tonnes. The available vehicles are listed in Table 2.

Vehicle	Capacity	Availability	Result
A	10 tonnes	Available	Eligible
B	6 tonnes	Available	Not eligible
C	12 tonnes	Unavailable	Not eligible

Only Vehicle A satisfies both conditions.

11.3Payment example

Assume that the order amount is ₹50,000. The customer makes two payments of ₹20,000 and ₹15,000.

Total payment:

₹20,000 + ₹15,000 = ₹35,000

Outstanding amount:

₹50,000 − ₹35,000 = ₹15,000

The remaining amount is ₹15,000.

12Testing and evaluation

The application should be tested module by module to check whether the recorded information and calculations are correct.

The test cases listed in Table 3 can be used.

Module	Test	Expected result
Login	Enter valid and invalid login details	Correct login response
User Roles	Access the application through different roles	Access follows assigned permissions
Inventory	Add received material	Stock increases correctly
Inventory	Record consumption and dispatch	Stock decreases correctly
Orders	Create and update an order	Correct order information is saved
Production	Record material consumption	Correct quantities are recorded
Vehicles	Check available and unavailable vehicles	Only suitable vehicles are considered
Delivery	Create a delivery trip	Trip information is saved correctly
Payments	Enter partial and full payments	Outstanding amount is calculated correctly
Diesel	Record fuel quantity and expense	Vehicle expense information is saved

Each test should record the input, expected output, actual output and pass/fail result. This makes it possible to identify errors and repeat the test after changes to the application.

The system can also be evaluated using real operational measurements. Examples include stock discrepancy, order processing time, delivery completion rate, vehicle utilization and diesel expense per trip. These measurements require actual company records collected over a defined period. No numerical improvement should be claimed without that evidence.

13Results and discussion

InfraMat brings the main record-management activities of GB Construction into one web-based application. Its modules cover inventory, suppliers, customers, orders, production, vehicles, delivery trips, payments and diesel expenses.

The main result described by the project is the organization of these activities within a common application. Records that are related during normal business operations can be maintained through connected modules. For example, material consumption is related to inventory, delivery information is related to orders and vehicles, and payment entries are related to customer transactions.

The application also separates users into four roles. This provides a way to organize access according to the work carried out by Admin, Manager, Driver and Customer users.

The stock, production, vehicle and payment procedures described in this paper explain the basic conditions and calculations involved in these activities. The sample calculations demonstrate the expected logic, while the graphs show examples of possible reporting outputs.

However, the available project information does not provide a formal test report, actual company dataset or before-and-after performance measurements. Therefore, this paper does not claim a measured reduction in processing time, material waste, fuel expenses or delivery delays. Such results would need to be established through testing and evaluation using actual business records.

14Contribution

The main contribution of InfraMat is the way it brings several related business activities into one application.

Inventory, production and order records are connected because each can affect material requirements. Vehicle and delivery records are connected because a delivery needs an assigned vehicle and driver. Payment and diesel records provide information about the financial side of operations.

The four user roles provide a separate way to access the system according to user responsibilities.

The project uses standard business calculations and record-management procedures. Its contribution is therefore practical and system-based rather than the invention of a new optimization algorithm.

Based on the documented project scope, InfraMat provides an organized approach to managing the listed activities of GB Construction. Its suitability for regular operational use should be confirmed through functional testing, permission checks, data-integrity checks and evaluation with actual business records.

15Limitations and future scope

The current project focuses on maintaining and connecting operational records. Some functions could be added in future versions.

Possible improvements include:

• A dedicated mobile application for users who need access away from a desktop.
• GPS-based live tracking of delivery vehicles.
• Automatic notifications when material quantities fall below a selected level.
• Online payment integration.
• More detailed sales, inventory and expense reports.
• Demand forecasting based on historical records.
• Supplier performance analysis.
• Vehicle-route optimization.
• Improved production and delivery scheduling.

These features would require additional development and testing. They are not included as current capabilities in this paper.

16Operational data design and record integrity

The usefulness of a connected management application depends on whether each business event is recorded once, associated with the correct reference and retained with enough context to be reviewed later. For InfraMat, the key design principle is to treat inventory movement, production consumption, order fulfilment, delivery and payment as related events rather than isolated form submissions. A transaction should carry a stable identifier, a date and time, the responsible user, and a reference to the business object that caused it.

Material records should distinguish a material's descriptive identity from its quantity movements. A material master record can hold a code, name, unit of measurement and other descriptive fields. Receipts, production consumption and dispatches should be stored as movement entries. The current balance can then be derived from the opening balance and the signed movements, or maintained as a cached value that is reconciled against the movement history. The movement history is important because a balance alone cannot explain why stock changed.

The same principle applies to orders and payments. An order identifier should remain stable even when its status changes. Payment entries should be separate records linked to the relevant order, because a customer may make more than one payment. The outstanding amount is then calculated from the order value and the sum of accepted payments. If a payment is corrected, the system should preserve an auditable adjustment rather than silently overwriting the earlier entry.

Database constraints can reduce avoidable data errors. Required fields should be checked before saving, identifiers should be unique, and relationships should use foreign keys where supported by the deployed database. Quantity fields should use consistent units, and conversions should be explicit. A delivery quantity expressed in tonnes must not be compared directly with a stock quantity expressed in kilograms unless the conversion is performed and recorded. Dates should use a consistent storage convention and be displayed in the local format expected by staff.

17Validation, exception handling and access control

Validation should occur at both the interface and backend levels. Interface validation helps a user correct an incomplete form before submission, but it is not a security boundary. The backend must independently check that identifiers exist, quantities are valid, a vehicle is available, and the requested operation is permitted for the authenticated role. This matters because requests can be sent without using the normal screen.

A stock update and its related transaction record should be committed together. If the movement entry is saved but the balance update fails, or if the balance changes without a corresponding movement, the records can disagree. Where several database writes are needed for one business operation, a database transaction should group them. On failure, the operation should be rolled back and the user should receive a clear message that the action was not completed.

Access control should follow the four documented roles: Admin, Manager, Driver and Customer. The exact permission matrix must match the implemented application and should be verified rather than assumed. A typical design would restrict system configuration and user administration to Admin, operational stock and order processing to authorised Managers, delivery-specific information to Drivers, and personal order information to the relevant Customer. This is a design example, not a claim that every permission listed is already implemented.

Passwords should not be stored in plain text. Authentication data should be handled through a recognised password-hashing mechanism, and sessions or tokens should expire according to the application's security policy. Sensitive actions, including changes to stock, order status, delivery assignment and payment records, should be logged with the user and timestamp. Backups should be protected from unauthorised access and periodically tested by restoring a copy.

18Reporting, indicators and management use

A dashboard is useful when it answers a specific operational question. An inventory view can show current balances and recent movements; an order view can group orders by their current status; a delivery view can show trips by date, vehicle or driver; and a payment view can distinguish total order value, payments received and outstanding amounts. These views should be derived from the underlying records and should display the period and unit used.

For example, the order fulfilment ratio for a selected period may be defined as the number of orders delivered during that period divided by the number of orders due during the same period. The definition must be documented because counting all orders created in a month and comparing them with deliveries completed in that month can mix different order cohorts. Similarly, vehicle utilisation should state whether it measures active hours, trips completed or load capacity used. A chart without a clear denominator can be visually persuasive but operationally misleading.

A practical reporting design should support filtering by date range, material, customer, supplier, vehicle and status where those fields are available. Users should be able to move from an aggregate value to the underlying records they are authorised to inspect. Empty or incomplete data should be labelled as unavailable rather than represented as zero. This distinction prevents a missing import or failed query from being interpreted as proof that no activity occurred.

19Deployment, maintenance and data migration

The documented project uses SQLite for local development and testing and MySQL for final deployment. Moving between these database engines requires attention to differences in data types, constraints, date handling, auto-increment behaviour and SQL syntax. A migration should therefore be tested with representative records before production use. The migration process should include a backup of the source data, schema creation, data transfer, row-count checks and verification of important relationships.

A deployment checklist should cover environment configuration, database credentials, application secrets, HTTPS configuration, error logging, backup scheduling and restoration testing. Secrets should be supplied through protected environment configuration rather than committed into source control. The application should avoid exposing stack traces or database details to ordinary users. Logs should be useful for troubleshooting while avoiding unnecessary exposure of customer or financial information.

Maintenance is not limited to fixing software defects. Material names, units, supplier details, vehicle availability and customer contact information can become outdated. The business should define who is responsible for reviewing these records and how corrections are approved. A periodic reconciliation of physical stock with recorded stock is also necessary; a digital balance cannot by itself prove that the physical quantity is correct.

20Evaluation plan

A fair evaluation should begin with a baseline period in which the business records its existing method of handling stock, orders, production, delivery and payments. After deployment, the same indicators should be collected over a comparable period. Possible measures include the proportion of stock records matching a physical count, time required to locate an order, percentage of orders with complete delivery records, payment reconciliation rate and frequency of duplicate or incomplete entries. The measurement definitions and data collection method should be fixed before comparing periods.

A small pilot can reveal workflow problems that are not visible during development. Managers may discover that a field is missing from a form, drivers may need a simpler way to view assigned trips, or customers may misunderstand a status label. Feedback should be recorded with the role of the user and the task being attempted. Changes should then be tested against the original requirements so that a usability improvement does not weaken data integrity or access control.

The interpretation of results must remain proportional to the evidence. A successful demonstration confirms that a selected workflow can be completed under the demonstration conditions; it does not establish long-term reliability or a reduction in business costs. Likewise, a sample chart illustrates a reporting design but is not evidence of an operational trend. InfraMat should be evaluated with real records over a defined period before numerical benefits are claimed.

21Conclusion

InfraMat was developed to manage the connected activities involved in a construction material business. The application brings inventory, suppliers, customers, orders, production, vehicles, delivery trips, payments and diesel expenses into one web-based system for GB Construction.

The frontend uses HTML, CSS, JavaScript and Tailwind CSS. Node.js and Express.js handle backend operations. SQLite is used during local development and testing, while MySQL is used for final deployment.

This paper described the system architecture, user roles, modules and operational workflow. It also explained the basic rules used for stock updates, production consumption, vehicle eligibility and payment balance calculations. Recent work on construction inventory, procurement and logistics was reviewed to show how the project relates to current research.

InfraMat's main contribution is the integration of business records that are normally connected during daily operations. The system provides a common place to maintain this information and organize access for different users. Further testing with actual company records will be needed to measure its operational impact and identify areas for improvement.

InfraMat provides a unified web application concept for the connected record-management activities of GB Construction. Its practical value lies in linking materials, suppliers, customers, orders, production, vehicles, deliveries, payments and diesel expenses within one operational environment. The paper has described the system's technology stack, user roles, modules, workflow and business rules, and has expanded the discussion to include record integrity, validation, security, reporting, deployment and evaluation.

The current project description does not establish measured improvements in stock accuracy, delivery performance, processing time or cost. Those outcomes remain matters for systematic testing and field evaluation. A deployment should proceed only after role permissions, database constraints, transaction handling, backup restoration and the core business workflows have been checked with representative data. Further work can then build on the common record base through mobile access, notifications, analytics and scheduling features.

References

1. [1]Carrillo YG, Mendoza Reategui J, Díaz Ruiz O. Improving project delivery compliance through integrated material planning, IoT-based inventory control, and warehouse layout design in a construction SME. Management Science and Industrial Engineering. 2026. https://doi.org/10.3233/ATDE260741
2. [2]Parisi L, Donyavi S, Flanagan R. Enhancing technology adoption in construction SMEs: Evaluating strategies for digital transformation in materials procurement. International Journal of Construction Management. 2026. https://doi.org/10.1080/15623599.2026.2669830
3. [3]Mohd NI. Digital material procurement and inventory management system for construction projects. International Journal of Research and Innovation in Social Science. 2026;10(14):386–399. https://doi.org/10.47772/IJRISS.2026.1014MG0032
4. [4]Guan Y, Shi G, Yang J, Shi J. An improved ant colony optimization algorithm for automated ready-mixed concrete distribution. Journal of Construction Engineering and Management. 2026;152(11). https://doi.org/10.1061/JCEMD4.COENG-18790
5. [5]Tibaldo AS, Montagna JM, Fumero Y. Efficient mixed-integer linear programming model for integrated management of ready-mixed concrete production and distribution. Automation in Construction. 2025;173:106074. https://doi.org/10.1016/j.autcon.2025.106074
6. [6]Buhaievskyi M, Petrenko Y. Planning and optimization models in ready-made concrete production and logistics. Radioelectronic and Computer Systems. 2025;(2):264–279. https://doi.org/10.32620/reks.2025.2.17
7. [7]Shah V, Shah SP. ERP-integrated inventory control and profitability in construction: A case study. Journal of Information Systems Engineering and Management. 2025;10(40s). https://doi.org/10.52783/jisem.v10i40s.7314
8. [8]Zhang H. Coordination mechanism of construction industry supply chain based on data elements. PLOS ONE. 2025;20(5):e0323748. https://doi.org/10.1371/journal.pone.0323748
9. [9]Mailana S, Ayumi V. Application ConTrack for inventory management and monitoring in a construction service company. JSAI (Journal Scientific and Applied Informatics). 2025;8(2):520–525. https://doi.org/10.36085/jsai.v8i2.8637
10. [10]Aritonang REB, Terttiaavini, Ariati N. Sistem informasi pengelolaan logistik bahan bangunan berbasis web pada PT Media Bersama Jaya Konstruksi. Jurnal Ilmiah Informatika Global. 2025;16(2):126–130. https://doi.org/10.36982/jiig.v16i2.5431