Development of a Low-Cost Web-Based Information System for Managing a University Department Chemical Warehouse

Abstract

Herein, we present the implementation of a low-cost web-based information system tailored to manage a university department chemical warehouse. The system provides a centralized platform for cataloging, tracking, and managing chemical inventory data, while also facilitating purchasing and various administrative tasks associated with laboratory operations. The system has been developed within the Campusnet platform and has the following functionalities: (i) an efficient way for cataloging the extensive array of products available in the warehouse; (ii) an intuitive web interface with a device-responsive layout to facilitate browsing and purchasing of products by students, researchers, and technical staff; (iii) an inventory transaction recording system to simplify the attribution of costs; (iv) a simple procedure to streamline the process of joint purchases; and (v) a low deployment cost and ease of maintenance. Key design considerations, including regulatory compliance and safety, are also presented.

1. Introduction

In academic and research settings, efficient management of laboratory resources, particularly chemical inventories, is critical to ensure efficiency, sustainability, regulatory compliance, and overall safety [1,2,3,4]. A well-organized information system tailored to the specific needs of a university department chemical warehouse can simplify the processes of products purchasing, inventory tracking, procurement of goods, waste disposal, and regulatory reporting [5]. Traditionally, laboratory resource management, including chemical inventories, has relied on manual methods such as paper record keeping, spreadsheets or local databases [6]. In more recent times, many university warehouses have networked their product catalogs through PDF files [7] or web-searchable HTML tables [8,9]. Although these methods may be sufficient for small-scale laboratories, they often prove inadequate for larger departments composed of many research and teaching groups with different supply needs. For instance, it is not uncommon to find departments with research groups operating in diverse areas of study such as chemistry, physics, biology, and engineering. Moreover, in the case of departments with teaching and research laboratories located in different buildings, consulting the chemical stock catalog can be complicated and highly inefficient if they are not accessible online. The lack of centralized management of the supply chain system can hamper teaching and research activities, resulting in the waste of resources, and can lead to the creation of small stocks in different laboratories with an increased risk of non-compliance with safety regulations.

In response to these challenges, there is a growing recognition of the need for technology-driven solutions to streamline laboratory resource management. Laboratory Information Management Systems (LIMS) adapted to the specific needs of laboratory environments have emerged as promising tools for enhancing efficiency, accuracy, and safety in laboratory operations [10,11,12,13]. These systems use advanced technologies such as the Relational Database Management System (RDBMS), barcode scanning, and even radio frequency identification (RFID) devices [14] to centralize and automate various aspects of laboratory and warehouse management.

While these systems are very powerful and well suited for an industrial setup, they come with some disadvantages that make them less than ideal for a university department and research setting. Firstly, they are costly to set up and maintain, with initial setup expenses often reaching tens of thousands of euros and ongoing operational costs like monthly user fees that many departments cannot afford. In addition, within a dynamic environment like that of a university department, managing licensing for every staff member or student who arrives or leaves would be challenging. Another disadvantage is that usually the chemical warehouse personnel have years of activity behind, where they have optimized processes and procedures that must be maintained. Purchasing software to use out of the box could mean to change those procedures and to adopt the new standards imposed by the software. Therefore, a solution designed around the procedures and needs of a particular warehouse could not only save money but also provide a tool capable of adapting to the true needs of both the warehouse staff and end-users.

In this article we report our working experience in creating a low-cost and web-based information system for managing a centralized chemical warehouse capable of meeting the needs of about forty research groups located in five different buildings within the Department of Chemistry, Life Sciences and Environmental Sustainability of the University of Parma. The system provides an efficient way to catalog the thousands of products available in the warehouse, and at the same time, it offers a quick and intuitive web interface to consult and purchase products without the need for prior instruction. The system also maintains a registry of all goods movements and has a reporting system to facilitate the attribution of costs to different accounts and research projects.

The organization of this paper is as follows: We first provide the readers with an overview of the current state of chemical warehouse inventory management practices and identify key challenges and limitations. Second, we outline the design considerations and requirement analysis for the development of the information system. Third, we describe the architecture and implementation details of the system, emphasizing features aimed at promoting efficiency. Finally, we discuss the potential benefits and implications of deploying such a system in a university department setting.

2. Key Challenges

The chemical warehouse of our department keeps an inventory of more than 6000 products including chemical supplies for teaching and research labs, laboratory glassware and plasticware, office and cleaning supplies, plus other miscellaneous items. The warehouse is in the basement of the Chemistry building and is managed by three technical staff members (warehouse managers). Their duties include maintaining stock levels of products, ensuring their safe storage in compliance with safety regulations, and distributing them to research laboratories according to their requests. The inventory of chemical products is managed through an MS Access database that is not accessible through the Internet. Thus, for each delivery, the warehouse managers must update product inventories in the MS Access database. Requests of chemicals or other goods are sent via text emails or phone calls and processed by the warehouse managers daily. Often, the lack of information for the precise identification of products (CAS number, size, grade, etc.), results in a time-wasting exchange of emails with the requesters. Considering that the warehouse receives an average of fifty requests each day, it is clear that this way of operating is highly inefficient and can be very tiring for the staff involved in the handling and delivery of products. Furthermore, the Prevention and Protection Service (SPP) of the University of Parma, in accordance with articles 36 and 37 of the Italian regulation on the safety and health of workers at work (D. Lgs 81/2008), requires departments to provide ready access to safety information for hazardous substances. Therefore, warehouse managers are obligated to maintain a copy of the Safety Data Sheet (SDS) [15], either in printed or digital formats (PDF files), for all the chemicals stored in the warehouse. Likewise, laboratories procuring chemicals are also required to maintain a copy of the SDS for each chemical purchased, in adherence to the same regulations. This laborious process not only consumes valuable time and resources but also has a negative impact on teaching and research activities that heavily rely on the prompt availability of laboratory material.

From this analysis, we have identified five key challenges that should be solved in order to drastically improve the efficiency and organization of the chemical warehouse. These key challenges include: (i) implementing of a web-based inventory-keeping software; (ii) enabling online access to the inventory database; (iii) providing e-commerce capabilities to users for easy purchasing; (iv) enriching product information with compound identifiers, properties, descriptors, and safety statements; and (v) implementing more efficient inventory tracking systems to ensure accurate stock levels and timely replenishment.

Before going into the details of software implementation, it is necessary to point out that, since 2015, our department has employed a locally developed web platform called Campusnet [16] on top of which various applications have been built to support students, faculty, and staff members in their daily duties. The platform was developed with WODA (Web Oriented DAtabase—https://sourceforge.net/projects/woda/ (accessed on 12 May 2024)) version 4.2, a Perl-based framework for web-based data management systems written by Žiga Turk in the late 1990s [17]. WODA facilitates the direct creation, editing, deletion, maintenance, and querying of relational databases with a web-based GUI and command line interface (CLI). The Campusnet platform is installed on a virtual Ubuntu Linux machine running Apache 2 web server. Given these premises, we have chosen to implement the warehouse management software as a Campusnet application, thus leveraging all the advantages provided by this platform such as user authentication, database administration, database maintenance, and ease of implementation. Furthermore, as all department personnel are already familiar with the Campusnet platform, adopting the new Digital Warehouse application will ensure a smooth transition and minimize the learning curve associated with the new procedures.

3. Design of the Digital Warehouse Database

The Digital Warehouse database relies on the implementation of six relational tables managed by corresponding Perl scripts fully integrated with the Campusnet platform (Figure 1 and

Table 1. Relational tables of the Digital Warehouse database.

Database Table	Expected Size
Products Stores information about products	3000 rows
Inventory Transactions Keeps a registry of product loading and unloading transactions	15,000 rows/year
Sale Orders Stores information on product purchases made by department personnel	3000 rows/year
Accounts Stores account data for costs attribution	500 rows
Suppliers Maintains the list of all manufacturers	250 rows
Joint Purchases Optimizes the order collection process to facilitate joint purchasing	20 rows/year

).

3.1. Products Table

The Products table holds product details like names, stock codes, descriptions, prices, locations, images, and document attachments. For chemicals, it also includes fields like the CAS number, IUPAC name, SMILES notation, synonyms, and molecular weight for accurate classification. A comprehensive list of the table fields can be found in Table S1. The Products table is linked to the Inventory Transactions table, the Sale Orders table, and the Suppliers table (Figure 1). The Products table is also connected to the other tables of the Campusnet platform, such as the Personnel UserTable, the Students UserTable, and the Spaces table, whose descriptions are beyond the scope of this article.

Each record in the Products table represents a single product item. This holds true even in cases where products of the same substance come in different grades, states, or sizes. For example, Ethyl alcohol with three different grades is stored in three independent records. This setup not only simplifies coding but also facilitates database maintenance, the recording of inventory transactions, and the allocation of costs.

The Products table records are stored and managed using WODA built-in routines. Each record encompasses the data fields illustrated in Table S1, except for the stock field, which is stored in a separate text file. Since the stock field holds the number of items currently available in inventory for each product recorded in the database, this design mitigates continuous database writes during inventory loading and unloading operations, thus optimizing database performance and reducing potential errors. The value of the stock field also establishes the maximum number of items that can be added to the shopping cart. When it reaches zero, the item cannot be purchased. However, due to the limited space available in the warehouse for storing goods, for certain products, especially those that are bulky or utilized only by one or two research groups, it may be necessary to manage them as “products without stock”. This classification means that such items can be added to the shopping cart and purchased by department personnel, but they would not be readily available for immediate delivery. Instead, they will be obtained from the supplier upon request, and the delivery will be entirely transferred to the requesting laboratory upon arrival. Essentially, the warehouse is committed to facilitating the purchase of these products but does not physically store them.

Another crucial feature of the Digital Warehouse is its capability to manage and track the movement of products within the campus. This is accomplished by assigning to each item of the Products table two identifiers: the room location and the shelf location. The room location contains the SIPE identifier, an information system used for location identification within the University of Parma [18], while the shelf location contains the shelf and the rack or cabinet identifier (see Implementation details and tools for further clarification). This setup enables department personnel to precisely locate any given product, also by means of the Campusnet mapping application that offers an interactive navigation across the campus [19] as well as within building floor plans [20].

Even though the department warehouse already has an MS Access database containing most of the available products and the WODA framework has routines to import comma-separated values, we have chosen to manually enter all the data fields to eliminate disposed items, thus ensuring the most comprehensive and accurate information possible. Hence, it is crucial to provide the warehouse managers with a data input GUI that is both user-friendly and quick to fill out, particularly for chemical products which entail more detailed information. Notably, sourcing data on the chemical properties of products (IUPAC name, synonyms, molecular formula and structure, molecular weight, and SMILES), as well as safety information (warnings, hazard pictograms, hazard statements, and precautionary advice), can be time-consuming and error-prone. Thus, to speed up the process and, at the same time, avoid mistakes and tedious work, we have implemented JavaScript helpers to assist with user data entry (see Implementation details and tools). First, chemical compound properties are retrieved from PubChem; second, safety information regarding the compound is extracted directly from the PDF file of the Safety Data Sheet; third, for chemical compounds, the atomic molecular structure is rendered from SMILES strings, thus eliminating the need to upload the corresponding digital image. Rendering the chemical structure of a compound in the list and product view pages (Figure 2) enables students and staff to visualize the arrangement of atoms within the molecule, thus aiding in the comprehension of its properties and reactivity and, at the same time, rising awareness of safety and disposal procedures associated with handling the compound.

The product page displays the signal word, pictograms, hazard statements, and precautionary statements contained in the Hazard Identification section of the SDS, so that they are immediately visible without the need to download and open the SDS PDF file. To further enhance safety precautions, we have also introduced an additional hazard class named “Extreme Danger” to identify substances capable of causing fatality through inhalation or contact (e.g., Hydrofluoric acid). Any inventory movement of these substances, beside what has been recorded in the Products Inventory table, triggers a notification alert which is sent via email to the department safety officer.

For products other than chemical compounds, uploading images of the product can greatly assist users in purchasing decisions. This is particularly important for glassware and plasticware products, where the name and description may not sufficiently convey their features. Images are uploaded to the Products table in various formats (PNG, JPG, or WEBP with a preference for the latter) and automatically processed server-side to reduce their size and generate thumbnail images for use in list contexts, thereby minimizing data transfer. Additionally, warehouse managers can manipulate the uploaded images directly in the browser, eliminating the need for time-consuming image editing and transfer operations (see Implementation details and tools). This setup allows them to input complete product information in less than two minutes.

To facilitate the purchasing of goods by the department personnel, we have incorporated e-commerce capabilities (see Implementation details and tools) into the Products application. Namely, logged-in users can add items to a shopping cart while browsing through available products, and then proceed to checkout by submitting the contents to the Sale Orders table (Figure S1).

Other tools available from the Products front-end include (i) a back-in-stock notifier that alerts users when an out-of-stock product is replenished; (ii) an understock GUI and querying system to easily display products that are running out of stock; and (iii) a barcode QR code generator and reader (see Implementation details and tools) to print labels that can be attached to the product packaging or affixed at the stockroom shelf (Figure 3). While chemical compounds typically come with clear information printed on their packaging, supplementing them with additional QR-coded labels allows users to get mobile access to detailed information, such as product specifications, usage guidelines, and safety precautions (SDS).

Likewise, warehouse managers can use QR-coded shelf labels to quickly load and unload goods from the inventory by using a mobile device. In addition to generating local QR codes, the Products table can also store the barcode data printed on the packaging of many products. Like QR codes, end-users can scan the barcode with a mobile device to access detailed product information. In this regard, a web GUI enables users to set the target destination of the QR code by selecting one of these four options: (i) product view page (default), (ii) product SDS file, (iii) product editing form, and (iv) product loading/unloading page. This setting is saved in the cookie and remains active for two hours.

3.2. Sale Orders Table

The Sale Orders table stores information related to the purchase of products by the department personnel. It encompasses data like order number, date, user ID, product ID, quantity, unit price, etc. (see Table S2 for a complete list). Each sale order can hold up to fifty products, but this limit can be adjusted through a global variable. The Sales Order table also includes the destination of the ordered products (SIPE identifier) used for location tracking and the Accounts table ID used for the attribution of costs. These fields are set by the purchaser before submitting the order form. The Sale Orders table also includes a state field which identifies the stages of the order process during its workflow. Valid values are the following: submitted, approved, processed, closed, and cancelled. Submitted orders are approved by the account holder and then processed by warehouse managers. Orders will be closed by the accounting manager once they have been charged to the account holder. At the submitted or approved stages, orders can also be cancelled, while at the processed stage, ordered products are unloaded from the stock, and transactions are recorded in the Inventory Transactions table. The Sales Orders table is linked to the Products, Inventory Transactions, Accounts, and Joint Purchases tables (Figure 1). The Sale Orders front-end provides warehouse managers with a web form for generating the daily delivery table of products (Figure 4) and provides the accounting manager with a web form for generating statements detailing expenses incurred within a given period.

3.3. Inventory Transactions Table

The Inventory Transactions table keeps a registry of every inventory movement conducted within the warehouse. This includes actions such as receiving new stock, transferring items between locations, fulfilling orders, disposing expired products, and any other changes in inventory quantity. The table stores the date of the movement, the product ID, the product name, the quantity displaced, the new destination of the product (SIPE identifier), and the reason for the movement together with the sale order ID and number (Table S3, Figure S2). The Inventory Transactions table is linked to both the Products table and the Sale Orders table through the product ID (Figure 1). This enables users to list all transactions associated with that product.

3.4. Accounts Table

The Accounts table contains information such as the type of account, account name and number, grant holder, and grant ID (Table S4), and it is used by the accounting manager for the attribution of costs. This table is utilized by the account holders to grant authorization to members of their research group (including students, researchers, and technicians) to specify the expense coverage when submitting a product request. Account holders can also establish a budget to set the spending limit and the dates during which the account is accessible for use. Finally, the account holders can periodically generate a report for each account managed, summarizing all expenses incurred in a given period of time. The Accounts table is linked to the Sale Orders table by the account ID primary key (Figure 1).

3.5. Suppliers Table

The Suppliers table contains all the vendors from which the department warehouse purchases the various products. The fields in this table include the supplier’s name, address, contact information, website URL, and local agent name and contacts (Table S5). The indication of the product supplier plays a crucial role in scientific research because it accurately identifies the origin and characteristics of materials to ensure experimental reproducibility.

3.6. Joint Purchases Table

The Joint Purchases table contains the various calls periodically opened by the warehouse managers to collect requests for a particular set of products or from a specific supplier. Each call includes a list of products the warehouse intends to purchase and/or the supplier from whom it intends to purchase. The fields in this table include a title, a description, open and closing dates, the supplier ID, the list of allowed product IDs, and a field to attach quotes and other documents useful for purchasing (Table S6). The Joint Purchases table is linked to the Products table and to the Suppliers table by their primary keys and to Sale Orders table by its own primary key (Figure 1).

The procedure for opening a joint purchase call is simple and straightforward. Firstly, the warehouse managers identify—based on specific requests, stock levels, and previous consumption—which products to include in the joint purchase. Next, they initiate a new joint purchase call by specifying a title and providing a description outlining the prerequisites for the collective order, also by attaching quotes and detailed specifications of the products allowed. After establishing the dates within which the joint purchase call is available, a banner pointing to the joint purchase view page will be displayed on the homepage of the Digital Warehouse web application. Students and staff will proceed as usual, adding the desired products to the shopping cart and then transferring them to the Sale Orders submission form, where they will be asked to specify the joint purchase they intend to participate in. This choice will link the sale order to the joint purchase by storing its primary key. After the call deadline, the warehouse managers list all the requests associated with that particular call and proceed with the purchase of goods from the suppliers. The account indicated in the various orders will be used for costs attribution. All joint purchase calls are retained in the archive for future rescheduling.

4. Implementation Details and Tools

4.1. The Application Front-End

The front-end of the Digital Warehouse application comprises a dynamically generated HTML5 and JavaScript-based web user interface with a fully responsive layout (Figure 2). All data entry, search, visualization, and database maintenance operations are carried out with the web browser. Automated and scheduled operations such as backups and email notifications are executed through the command line using the Linux crontab command. An Android app with a jQuery Mobile front-end is also available (Figure S3).

4.2. Chemical Compound Data Sourcing

Chemical compound data, including the title, IUPAC name, SMILES, molecular formula, molecular weight, and synonyms, are fetched from PubChem via the PUG REST API (https://pubchem.ncbi.nlm.nih.gov/docs/pug-rest (accessed on 12 May 2024)) [21] by using the CAS number as a query identifier. The product name is translated in Italian (or any other language) using the MyMemory Translation API (https://mymemory.translated.net/ (accessed on 12 May 2024)). The retrieved data are formatted in JSON and returned to the client, where they are used to populate the corresponding fields of the Products table input form. This procedure allows warehouse managers to oversee the retrieved information before storing it into the database.

4.3. Chemical Structure Rendering

The molecular structure of chemical compounds is drawn client-side by using SmilesDrawer (v1.0) [22], a JavaScript library capable of rendering molecular structures from SMILES strings. Rendered images can be generated either in SVG or PNG format. The rendering process is very fast and can be utilized also for presenting list views with many structures to display (Figure 2).

4.4. Image Resizing and Enhancement

Server-side image processing, mainly image resizing, is performed with PerlMagick which provides a Perl interface to GraphicsMagick (v1.3.35) (http://www.graphicsmagick.org/ (accessed on 12 May 2024)). Client-side image manipulation is accomplished using Filerobot Image Editor (v4.7.0) (https://github.com/scaleflex/filerobot-image-editor (accessed on 12 May 2024)), a JavaScript library designed for resizing, cropping, flipping, enhancing, and annotating uploaded images within the web browser.

4.5. Extraction of Safety Information from the SDS File

Safety Data Sheets for chemical products are commonly distributed as PDF files, presenting information in a structured layout that facilitates text parsing and data extraction. We have implemented a simple extraction procedure that consists of uploading the SDS PDF file provided by the supplier to the server and converting it into a text file using the command-line program pdftotext. A Perl text parser script extracts safety information such as the SDS date, signal word, pictograms, and hazard and precautionary statements by using predefined keywords. This information is then sent back to the client in JSON format and utilized to populate the corresponding fields of the Products table input form.

4.6. QR Code Generation and Detection

QR codes used to compose product labels are generated by using the QR code generator web API (https://api.qrserver.com/v1/create-qr-code/ (accessed on 12 May 2024)). The QR code contains the URL of a target script (/do/magazzino.pl/Go) that redirects the web browser to a product page (see above) based on the ID provided in the URL and on cookie settings. QR code detection is performed with the Campusnet QR code reader which has been developed with the Html5-QRCode JavaScript library (https://github.com/mebjas/html5-qrcode (accessed on 12 May 2024)). The internal QR code reader application allows for the customization of the scanned data. For example, after scanning a barcode, the application sends a query to the warehouse database. If a match is found with the scanned barcode, the user is directed to the target script (/do/magazzino.pl/Go) for proper redirection. This setup not only enables users to utilize the QR code or the barcode for various tasks but also permits future developments to exploit the encoded information without requiring label updates.

4.7. Shopping Cart Implementation

The shopping cart has been implemented by using cart-localstorage, a simple and easy-to-use JavaScript shopping cart library that utilizes the browser localStorage to create a persistent shopping cart instance (https://github.com/peet86/cart-localstorage (accessed on 12 May 2024)). A GUI assists users in visualizing and managing shopping cart items before finalizing their purchase by submitting them to the Sale Orders table (Figure S1). Procedures for saving and retrieving the shopping cart list of items from the server have been implemented to allow users to retain the content when switching devices or browsers. Additionally, routines are available to export and import the shopping cart list to a CSV file, enabling the exchange of items among users.

4.8. Data Export

The Campusnet platform provides server-side routines for data import/export using CSV formats. However, to better support warehouse managers in their daily duties, we have enhanced table views, particularly those reporting data for delivery and accounting (Figure 4), by adding the client-side capability to export the displayed data into XLSX files using the JavaScript library SheetJS (https://sheetjs.com/ (accessed on 12 May 2024)). With this library, warehouse managers can export data from the web application into spreadsheet formats, allowing them to conveniently download the data for further processing.

4.9. Location Identifiers

The room identifier (SIPE) consists of a numeric string with the format: 00.00.0.000, where the first two digits represent the geographical area, the second two digits identify the building, the third single digit identifies the floor, while the last three digits identify the room or space. The shelf identifier consists of an alphanumeric string with the format S00.R00, where the first half of the string identifies the rack or cabinet while the second half identifies the shelf. For instance, the location of the 2-Aminobenzoic acid shown in Figure 2B is 13.01.S.126 S01.R03, meaning that this item it is stored in the basement (S) of the Chemistry building (01) at the University of Parma Campus (13), room 126, on the third shelf (R03) of the first rack (S01).

4.10. Other JavaScript Tools

The following JavaScript tools have been installed to enhance functionality and to improve the user experience of the Digital Warehouse web application: TinyMCE (v4.8), a JavaScript library for rich text editing (https://github.com/tinymce/tinymce (accessed on 12 May 2024)); Dropzone.js (v6.0), a JavaScript library for handling file uploading with drag-and-drop functionality (https://github.com/dropzone/dropzone (accessed on 12 May 2024)); ScanDoc, an in-house application built on Dropzone.js to upload pictures captured with smartphone cameras directly into the Digital Warehouse database; Tiny Slider (v2.9.4), a JavaScript library for creating carousels (https://github.com/ganlanyuan/tiny-slider), providing an effective way to showcase a list of related products; and Tablesort (v5.4), a JavaScript component useful for sorting tables client-side (https://github.com/tristen/tablesort (accessed on 12 May 2024)).

5. Final Considerations

The implementation of a web-based information system for managing the chemical warehouse has proven to be a significant strategic choice within the overall organization of the department. On one hand, it has allowed staff and students to have an easily accessible catalog containing all the products readily available within the campus; on the other hand, it has enabled warehouse managers to fulfill their duties in a more organized and efficient manner. The primary motivation behind this effort stems from the fact that over the past three years, our department has experienced an unprecedented increase in the number of funded projects, also thanks to the National Recovery and Resilience Plan (PNRR). This sudden influx of resources has resulted in both an increase in research personnel and material requests. At the same time, the administrative machinery in charge of the purchases has not been adapted to the new demands, causing a supply chain bottleneck and resulting in prolonged waiting times (in the order of months) for obtaining goods. In this context, a centralized system provides several benefits: First, it offers a large selection of products that are immediately available for use; second, it ensures inventory tracking and safety and regulatory compliance for the utilization of substances in the different laboratories; and third, it opens the possibility for a joint purchasing strategy, which represents the ultimate goal of our transition toward a more efficient and sustainable acquisition process. This modus operandi not only allows retrieval of the needed goods quickly (within the same or next day), but effectively cuts acquisition, storage, and disposal costs. Another advantage of joint purchasing is the increased leverage it provides in negotiations with suppliers. Because of the substantial volume of requested products combined into a single order, warehouse managers gain greater bargaining power, enabling them to negotiate more favorable terms and lower unit prices of products.

The new procedures of the Digital Warehouse have been approved by the Department council and the transition from the old system to the new one took place within a week in January 2024 without causing any service interruption or significant inconveniences. After two months of activity, the Digital Warehouse has processed about 500 orders with more than 2000 products delivered. Changes to the code since then have been limited to a few layout improvements. However, as is often the case with web-based services in a university setting, the major challenge lies not in the initial development and installation of the software, but rather in its long-term maintenance, which entails staying current with browser developments and emerging technologies. To this end, the department is considering the necessity of new personnel who can take the lead in maintaining and advancing the many web services available within the Campusnet platform.

With the implementation of the Digital Warehouse, we also took the opportunity to reorganize the products in the various stockrooms by replacing old shelves and cabinets, removing unnecessary or expired items and by designating new locations for easy and timely retrieval, in accordance with the guidelines outlined in the 5S Manual [23]. This logistic reorganization freed up space to accommodate new products, particularly those requested by research groups who had not previously utilized the department’s chemical warehouse service.

To summarize, we have presented several open-source solutions used for the development of a low-cost web-based information system capable of managing a chemical warehouse in an academic and research setting. Although significant technological improvements have been introduced, we acknowledge that we are not utilizing state-of-the-art solutions, especially for the database management system WODA, which was proposed in the 1990s but that has not been further developed compared to more modern solutions like MySQL or similar RDBMSs. While not conventional, over the years, WODA has proven to be a flexible and reliable data management system with excellent performance for small-sized databases such as those considered in this article. The decision to utilize WODA is justified by the aim to integrate the Digital Warehouse application within the Campusnet platform which already hosts more than twenty other web services for our department. Additionally, the Campusnet platform is designed to manage multiple instances within the University context, meaning that the infrastructure and procedures we have developed could be extended to all departments, with substantial benefits throughout the entire institution.