BPDM Input Interface for Non-Sharing Members

[jjeroch]

Objective:

To develop a user-friendly input interface for non-sharing members, enabling them to create and add their company structures, including sites and addresses, which can then be uploaded to the shared pool via the BPDM (Business Partner Data Management) Gate.

User Stories:

As a non-sharing member, I want to easily input my company's structure into the BPDM system so that it can be accurately represented without sharing sensitive data.

Functional Requirements:

1. User Authentication:

   • Users must be authenticated to ensure only authorized personnel can add company data.
   • The system should support standard authentication methods such as SSO (Single Sign-On).

2. UI for Company Structure Input:

   • The interface should allow users to input various levels of their company structure, including:
     • Parent company
     • Subsidiaries
     • Divisions
     • Individual sites
   • Users should be able to input address details for each site, including:
     • Street address
     • City
     • ZIP/Postal code
     • Country

3. Data Validation:

   • The interface must validate data to ensure it matches BPDM format requirements.
   • Validation checks should include data type checks, mandatory field checks, and pattern matching for addresses.

4. Data Upload and Integration:

   • Once the company structure is inputted and validated, the system should enable uploading to the BPDM pool via the BPDM Gate.
   • The upload process should handle data mapping to ensure compatibility with the BPDM data model.
   • The system should provide feedback on the upload status and any errors encountered.

5. Error Handling and Reporting:

   • The system must provide clear error messages for data input mistakes or upload issues.
   • Users should be able to download error reports for troubleshooting and record-keeping purposes.

6. User Help and Support:

   • The interface should include help sections, tooltips, and a user manual for guidance.
   • Support contact information should be readily available for users requiring assistance.

7. Preview and Edit Capabilities:

   • Users should be able to preview their company data before uploading.
   • The system should allow editing of the company data in case any changes are necessary pre-upload.

Non-Functional Requirements:

1. Usability:

   • The interface should be intuitive and easy to navigate.
   • The design should be responsive to accommodate various devices.

2. Performance:

   • The interface should handle inputs and uploads promptly.
   • The system should be optimized for minimal downtime.

3. Scalability:

   • The system should be scalable to accommodate growing numbers of non-sharing members and data volume.

4. Maintainability:

   • The code should be well-documented and follow best practices to ensure ease of maintenance.

Acceptance Criteria:

• The interface allows non-sharing members to create and add their company structures accurately.
• The system validates the input data according to BPDM standards.
• Users can successfully upload their company structure to the BPDM pool via the BPDM Gate.
• The system provides clear feedback, error messages, and support options for users throughout the process.

---

Test Cases

Test Case 1: User Authentication

Objective: Ensure that only authorized users can access the company structure input interface.

• Test Steps:

  1. Attempt to access the company data management UI with the correct permissions assigned.
  2. Attempt to access the company data management UI with the incorrect permissions assigned.

• Expected Results:

  1. Access granted.
  2. Access denied.

Test Case 2: UI for Company Structure Input

Objective: Verify the user interface allows for correct input of company structure data.

• Test Steps:

  1. Log in as an authorized user.
  2. Input data for parent company, site and addresses.
  3. Enter address details for each site.

• Expected Results:

  1. User is able to log in successfully.
  2. The interface accepts input for all required levels of company structure.
  3. Address details for each site can be entered without issues.

Test Case 3: Data Validation

Objective: Confirm that the interface correctly validates input data.

• Test Steps:

  1. Enter invalid data, such as incorrect address formats or missing mandatory fields.
  2. Submit the data for validation.

• Expected Results:

  1. The system flags the errors and does not allow submission until corrected.
  2. Error messages specify the exact nature of the validation failure.

Test Case 4: Data Upload and Integration

Objective: Ensure that validated company structure data can be uploaded to the BPDM pool.

• Test Steps:

  1. Validate company structure data.
  2. Initiate upload to the BPDM pool.
  3. Check for feedback on upload status and errors.

• Expected Results:

  1. Data passes validation checks.
  2. Data upload process begins, and system handles data mapping.
  3. System provides feedback on the upload process and any errors encountered.

Test Case 5: Error Handling and Reporting

Objective: Evaluate the system's error handling and reporting mechanisms.

• Test Steps:

  1. Introduce a data input error or upload issue.
  2. Check the error messages and attempt to download an error report.

• Expected Results:

  1. System provides a clear error message related to the issue.
  2. Error report is downloadable and contains detailed information for troubleshooting.

Test Case 6: Preview and Edit Capabilities

Objective: Check that users can preview and edit company data before confirming.

• Test Steps:

  1. Enter and validate company data.
  2. Use the preview function to review data before confirming.
  3. Make edits to the company data and validate the changes.

• Expected Results:

  1. Data is validated successfully.
  2. Preview displays the company data as it will appear post-upload.
  3. Edits can be made, re-validated, and saved correctly.

Test Case 7: Usability

Objective: Assess the interface's ease of navigation and responsiveness.

• Test Steps:

  1. Navigate through the various sections of the interface.
  2. Access the interface from different devices to test responsiveness.

• Expected Results:

  1. Interface is intuitive and easy to navigate.
  2. The design adjusts to different screen sizes and devices without issues.

Test Case 8: Performance

Objective: Determine if the interface handles inputs and uploads with acceptable speed.

• Test Steps:

  1. Time the input process for a complex company structure.
  2. Time the upload process for validated company data.

• Expected Results:

  1. The input process is completed in a reasonable amount of time.
  2. The upload process is completed promptly without unnecessary delays.

Test Case 9: Scalability

Objective: Verify that the system can handle an increased load (under this epic we only concentrate on displaying a huge number of company data - sites, adresses, etc. & as well as simultaneous data entries)

• Test Steps:

  1. Simulate a high number of users inputting data simultaneously.
  2. Simulate an increased volume of data being fetched from the BPDM Gate and displayed in the FE UI.

• Expected Results:

  1. The system maintains performance under increased user load.
  2. The system processes large volumes of data without significant degradation in performance; UI elements are able to handle the volume.

---

Linked Tickets:

• https://github.com/eclipse-tractusx/portal-frontend/issues/623
• https://github.com/eclipse-tractusx/portal-frontend/issues/887
• https://github.com/eclipse-tractusx/portal-frontend/issues/888
• https://github.com/eclipse-tractusx/portal-frontend/issues/941
• https://github.com/eclipse-tractusx/portal-frontend/issues/942

[jjeroch]

@maximilianong ideally we should add here your tickets for the bpdm backend changes/implementations as well

[jjeroch]

Test Cases added ✅ likely some updates and details are still needed; but initial input provided

[MaximilianHauer]

@maximilianong brauchen wir das feature noch ? scheint ja eher seitens der expert group mit #754 umgesetzt zu werden