Bulk Upload Management for Records

Approver	Sumeet Shekhar Ajit Vijay DawareUser e8ff2
Contributors / Driver	Naveen Varma Roda
Senior Arch / Reviewer	Rahul Singh Ramesh Varma Kutcherlapati
Extended Link	https://maersk-tools.atlassian.net/wiki/x/GIJKmSo

To provide users with a streamlined interface for efficiently uploading and managing records with multiple attributes, including communications, email, and contact details etc... This feature aims to simplify data entry, ensure data integrity, and enhance user experience by allowing easy updates and modifications of records in a structured format.

To implement a bulk upload feature for handling records with multiple attributes, we can consider several approaches. Each approach has its pros and cons based on our requirements for maintainability, ease of use, and flexibility. Here's a breakdown of some options:

1. Single Row Concept
2. Multiple Rows with facility code during update flow
3. Separate template for multi-value attributes
4. Streamlined Bulk Upload with Single-Value Attributes and Manual Multi-Value Updates via Portal

Single Row Concept:

Structure: Each record has a single row with multiple columns representing attributes. (While create & update)

Pros:

• Simple structure for a single record.
• Easy to understand.

Cons:

• Difficult to manage when we have multiple values for the same attribute (e.g., multiple email addresses).
• Potentially leads to sparse data with many nullable columns.

Implementation:

• Define a table where each attribute is a column. For multi-valued attributes, concatenate values (e.g., code | code1).
• Parse these values in our service layer.

Multiple Rows with facility code during update flow:

Structure: Use a fact code to group related records, with each row containing a full set of attributes.

Pros:

• More normalised data model.
• Easier to manage multi-valued attributes.

Cons:

• Requires the user to enter all attributes for each row, which can lead to redundancy and increase the chances of error.

Implementation:

• When updating, retrieve the related attributes based on the fact code and allow the user to update them.

Separate template for multi-value attributes

File Template Structure:

• Fact Code (Primary Identifier): Column for unique fact code to identify the section.
• Facility Type: Separate columns for each facility type
• Multi-Value Separator: Use delimiters (e.g., semicolon ; or pipe |) to separate multiple values in a single cell for fields like phone numbers or emails or name or valid through date.

Example Template:

Sce 1

Fact Code	Facility Name	Relationship Valid through	Action
FC001	Depot	DD/MM/YYYY	UPDATE
FC001	Depot	DD/MM/YYYY	DELETE
FC001	Depot	DD/MM/YYYY	MODIFY
FC001	Depot	DD/MM/YYYY	DELETE

Sce 2

Fact Code	Facility Name	Relationship Valid through	Is Deleted
FC001	Depot | Off-Hire Depot	25/07/2024	Modified
FC002	Off_Hire Depot	25/07/2024	Delete
FC003	Off_Hire Depot	25/07/2024	Update

Pros:

1. Granular Control: Users can specify different actions for each section / facility type in the same record.
2. Data Integrity: Ensures all operations (insert, update, delete) are well-defined and validated.
3. User-Friendly: Flexible for users who want to manage specific contacts without affecting others.

Cons:

1. Complexity in Processing: We need to write logic to parse the multi-value attributes, split them, and ensure each value is valid.
2. Harder Error Tracking: If there’s an error in one value among many (e.g., in facility name), it may be more difficult to locate the issue.
3. Potential for Overloaded Cells: If too many values are included in one cell, users may find it hard to read or modify.

Implementation: Yet to come conclude

Streamlined Bulk Upload with Single-Value Attributes and Manual Multi-Value Updates via Portal:

In this approach, We ask users to create or update records with only single values per attribute (even for attributes that may eventually hold multiple values, like contact details). Later, users can log into the portal and manually add or update multiple values for attributes directly at the record level.

File Template Structure: Each record would have only one value per attribute (e.g., one phone number, one email, one address). Additional values would need to be added manually via the portal.

Example Template:

Fact Code	Contact Type	Contact Value	Address	Email
FC001	Phone	1234567890	123 Main St	email1@example.com
FC002	Phone	2345678901	456 Maple St	email2@example.com

• Fact Code: Primary identifier for the record.
• Contact Type: Specifies whether the contact is a phone number, email, etc.
• Contact Value: The actual value (one per row in this case).
• Address, Email: These are other single-value attributes.

Pros:

• Users only need to provide one value for each attribute, making it easier to understand and fill out.
• Reduces complexity in the file, leading to fewer issues like formatting errors or multi-value parsing problems.
• Users can fine-tune and add additional values manually later through a user-friendly interface on the portal.
• We can enforce stricter validation since each attribute only has one value (e.g., a single email or phone number per record).

Cons:

• Users must manually update or add multiple values for each record in the portal, which might be time-consuming.
• Bulk uploading becomes less powerful for complex records that inherently involve multiple values (e.g., multiple phone numbers or emails).
• Users need to complete records post-upload, leading to incomplete data until the manual entry is done.
• Users who prefer doing everything via bulk upload may find this less efficient.