Proposal For Update Website with New Version (SCA 2024.2) and Domain-Specific

 

Proposal Summary 

This proposal covers the scope of updating the current website setup to support multiple domains based on subsidiaries while ensuring that the required customizations and extensions function appropriately for each domain. Additionally, the website needs to be upgraded from SCA 2019.1 to SCA 2024.2, ensuring that all customizations and features are compatible with the new version. 

 

The estimated time for the completion of the proposal is 284 Hours. 

The scope and the provided estimate are based on the anticipation, expectation, and understanding through our discussions and email. If the scope change/additional feature development identified during actual development, they will be treated as change request. 

Scope of Work (SOW): 

A. Website Upgrade: 

1. Upgrade SuiteCommerce Advanced (SCA) from Version 2019.1 to 2024.2: 
2. Review all customizations and extensions implemented in the 2019.1 version to identify any compatibility issues with version 2024.2. 
3. Ensure all core features (like the homepage, cart, checkout process, product detail page) are functioning as expected after the upgrade. 
4. Reconfigure or rewrite any deprecated custom scripts or modules as per the new version’s requirements. 
5. Update dependencies, plugins, and third-party integrations to match the requirements of SCA 2024.2. 
6. Test for Cross-Domain Compatibility: 
7. With the introduction of multiple domains, conduct end-to-end testing across all domains (UK, AU, NZ, US, NL, etc.) to ensure that the new multi-site architecture functions as expected. 
8. Ensure that global and domain-specific features behave correctly across the different domains/subsidiaries. 

 

B. Domain-Specific Customizations and Extensions: 

• Barcode Extension: 

1. Action: Continue to be reusable across all domains without any changes. 
2. Implementation: Ensure compatibility with the new version, and confirm it works as expected across all domains. 

• CheckoutPagePurchaseOrderField: 

1. Action: Make this feature configurable to allow activation across all domains. 
2. Implementation: Refactor the extension to handle subsidiary-specific configurations. 

• DeliverymethodUK: 

1. Action: Make this extension configurable for use across all subsidiaries. 
2. Implementation: Allow flexibility in assigning delivery methods to each subsidiary’s domain. 

• HideShipping: 

1. Action: Ensure this feature can be activated based on each subsidiary’s domain. 
2. Implementation: Refactor to add configurability and make it domain specific. 

• HomePageCarousel: 

1. Action: Keep the carousel feature consistent across all domains, customized for subsidiary-specific images. 
2. Implementation: Ensure no changes are required, but test for functionality in multi-domain setups. 

• Invoice_Paynow_Button: 

1. Action: Modify the extension to activate for any subsidiary domain as needed. 
2. Implementation: Implement configurable activation for each subsidiary. 

• JJ_SCV_Import (CSV Import for Cart): 

1. Action: Enable this feature for all subsidiary domains in the multi-site setup. 
2. Implementation: Ensure that the import functionality works seamlessly for all domains. 

• Limitpurchase: 

1. Action: Continue as-is across all domains. 
2. Implementation: Confirm functionality after the upgrade. 

• PaymentOption: 

1. Action: Continue to apply this feature across all domains. 
2. Implementation: Ensure flexibility in terms of availability for each subsidiary. 

• PurchaseListUpdate: 

1. Action: Continue to apply this update across all domains without modification. 
2. Implementation: Confirm that this functionality works without issues across multiple domains. 

• RestrictField: 

1. Action: Modify to handle restrictions based on the subsidiary. 
2. Implementation: Update the extension to be domain-specific for editable fields, such as company name and address. 

• RestrictItems: 

1. Action: Continue activation for all domains. 
2. Implementation: Test for domain-specific restrictions applied correctly to the shopping cart and checkout. 

• SearchContact: 

1. Action: Continue activation for all domains. 
2. Implementation: Ensure the “Ordered by” field works across all subsidiaries. 

• SiteSpecific_Extension (Web Store Description): 

1. Action: Update to apply across multiple locations and for all subsidiary domains. 
2. Implementation: Refactor the feature to make it compatible with multi-domain configurations. 

• Stock_Status: 

1. Action: Update to support multiple 3PL locations and apply the feature for all subsidiaries. 
2. Implementation: Refactor to ensure that stock status is correctly displayed based on the correct 3PL location for each domain. 

• ThirdParty_Shipping: 

1. Action: Extend the third-party shipping method functionality to other domains as required. 
2. Implementation: Make this feature configurable for each subsidiary’s domain. 

Customization features available through modules 

• Changes related to the promo code have been added. 
• Category and subcategory updates based on the subsidiary are included. 
• Subsidiary-related mini cart updates have been added. 
• The home view has been extended and customized. 
• Item-based customization has been implemented to display the stored display name. 
• Promotion-related updates have been applied. 
• Promotion-related changes have been made. 
• Enhancements for handling out-of-stock items added to the cart from the Wishlist. 
• The search bar is now always visible on navigation, based on screen size. 
• Actions: The implementer will move the custom modules to extensions, ensuring that customizations work based on the subsidiary. 

C. Skin and Branding for Different Domains: 

• Custom Skins for Each Domain: 

1. Action: Develop and implement distinct skins for each subsidiary’s domain. 
2. Implementation:  
3. Define a new CSS/JS structure for each domain to differentiate the branding, colors, and design elements. 
4. Ensure that the homepage and product pages reflect the correct skin based on the domain/subsidiary. 
5. Update theme files to ensure each domain gets its specific layout and branding. 

• Customizable Theme ConOfiguration: 

1. Action: Create a flexible, configurable theme structure that can be easily updated for each domain.  
2. Design- The implementer will use the existing design for the new version as well.  
3. Implementation: Refactor the theme structure to allow domain-specific overrides (i.e., banners, and color schemes). 

D. Multi-Site Implementation Strategy 

This phase focuses on the technical aspects of implementing the multi-site architecture: 

• Domain Setup: The implementer will create a custom field in the customer record to store the domain name during customer registration/login. Separate domains will be configured for each subsidiary: Below are some sample suggestions. 
• AU: .com.au 
• UK: .co.uk 
• NZ: .co.nz 
• USA: .com 
• CA: .ca 
• NL: .nl 
• Website Configuration: The implementer will configure NetSuite to link each domain to its corresponding subsidiary. Each domain will have region-specific products, categories, and pricing, and the user experience will be localized for each region. 
• Tax & Payment Configurations: Each subsidiary will have tailored tax schedules and payment methods. Tax is generated based on standard NetSuite tax settings and configurations for each subsidiary. The implementer will assign the promotion code and the special items to the appropriate subsidiary/domain. 
• Shipping & Inventory: The shipping methods and inventory checks will be region-specific, ensuring accurate stock levels are shown. Currently, the shipping methods are displayed based on the subsidiary. This feature will continue to be applied across all domains. 

Website Flow & Process Design 

Customer Authentication and Registration 

• New Customer: 
• Customer registration is managed by a third party. The third party must use the subsidiary field in the customer record during registration or when granting access, ensuring that customer record created under the proper subsidiary for adding the restriction based on the domain (based on subsidiary) 
• Once the customer registers, the order process begins. 
• Existing Customer: 
• Forgot Password: 
• If the customer indicates they forgot their password, a password reset email is sent. 
• Login: 
• If the customer logs in successfully, the system populates the subsidiary field with the current domain name, ensuring that customers are restricted by domain. 
• Once the customer logs in, the order process begins.   

Order Processing Function: processOrderFlow 

When the order process is initiated, the following steps occur: 

• Customer Website Visit 
• The system checks if the customer has visited the website. 
• When the visit is confirmed, the customer can browse products, including special items and categories. These are shown based on the current domain or subsidiary. 
• Inventory Check and Cart Actions 
• Inventory Available: 
• If the product is in stock, the customer can add it to their cart. 
• The system then shows shipping options that are specific to the domain/subsidiary. 
• Inventory Not Available: 
• The system will display an “out-of-stock” message. 
• The “Add to Cart” option will be hidden. 
• Order Placement and Post-Order Actions 
• Order Placed: 
• Order Cancelled: 
• If the customer cancels the order after placing it, an order cancellation email is sent. 
• Order Validated: 
• The system applies domain or subsidiary-specific settings (like currency and tax). 
• The order is pushed to NetSuite for processing. 
• The order is fulfilled. 
• A confirmation email is sent to the customer.  
• An invoice email with order details is sent to the customer. (The order confirmation and invoice email templates are the same for all subsidiaries. Additional customization is needed for domain-specific templates) 
• Order Error: 
• If the order cannot be validated, an error handling process is executed. 

Deliverables 

• Analysis Report: Detailed review of existing customizations and required modifications for multi-site compatibility. 
• Multi-Site Implementation Plan: Strategy and steps for setting up each domain and ensuring subsidiary-specific customizations. 
• The implementer will create a custom field in the customer record to store the domain name during customer registration/login.   
• Flow Diagram: Visual representation of the multi-site architecture and order process flow. 
• Email Templates: Email templates will remain unchanged. Any modifications to any email template will be treated as a change request. 
• Configuration Documentation: Clear documentation detailing configuration steps for each subsidiary. 
• Testing and Validation Plan: A comprehensive plan for validating the setup after deployment. 
• An email must be sent to notify the customer about the multi-site setup.   

Prerequisites: 

• The implementer requires a sandbox account and staging domain for all the six domains. 

Scope Limitation 

• Full NetSuite OneWorld Setup: Assumes that the NetSuite OneWorld environment is fully configured with multi-subsidiary support. 
• Access to Current Configurations: The client will provide access to existing website configurations and necessary credentials. 
• Website Setup: As there is only a single website with multiple domains, all features configured in this website setup will be applied uniformly across all domains. 
• This proposal does not cover additional third-party integrations.  
• Future scope changes may require additional effort estimates.  
• Customer data migration is outside the current scope. 
• SCA themes come with certain constraints in terms of layout and modularity. Some level of customization is limited by how the SuiteCommerce theme and layout system is structured. 
• There may be limitations in the base theme provided by SuiteCommerce Advanced that prevent advanced modifications without heavy customization of the base templates.  
• Integration with SuiteCommerce Back-End: 
• Custom skins may need to interact with SuiteCommerce backend functionality like SuiteScript and SuiteCommerce APIs. If not carefully integrated, these custom skins could cause integration issues during the upgrade, especially if the API versions are updated. 
• A major redesign beyond skin updates is not included. 
• No domain-specific changes are included for the email notification templates. 
• Control Brand Visibility per Customer Group:  
• Solution 1: Website performance issues may arise if more data is added to the configuration record. 

Assumptions 

• Full NetSuite OneWorld Setup: Assumes that the NetSuite OneWorld environment is fully configured with multi-subsidiary support. 
• Access to Current Configurations: The client will provide access to existing website configurations and necessary credentials. 
• Bundle Installation – The latest version bundle needs to be installed on the production account. It would include a new SCA version, extension manager. 

After that, a sandbox refresh will be required to reflect these changes in the sandbox account. 

• Custom extensions will be configured dynamically. 
• Website design will remain consistent across all domains.  
• Customer registration will be handled by third party.  
• Currently, only logged-in customers have access to the website. This will remain the same for all domains. 
• The client will provide a domain for testing the multi-site setup.  
• The client will provide a total of 11 domains: 5 for sandbox and 6 for production. Since the implementor is considering an existing domain in the sandbox, it can be used for the AU subsidiary. 
• Client has a 3CX account with live chat enabled. 
• A single 3CX account can support multiple domains, but all domains will share the same chat team, settings, and agent routing. 
•  If different chat settings, teams, or separate analytics per domain are required, separate 3CX accounts will be needed for each domain. 
• WhatsApp Business API access is available. 
• A single WhatsApp Business API account can be linked to multiple domains. 
• Each domain can use the same WhatsApp number, but messages will be handled centrally. A single chatbot or support team can manage customer interactions across all domains. 
• NetSuite RESTlet deployment is permitted. 
• External API calls to WhatsApp are allowed. 
• External API calls to 3CX are allowed. 
• Control Brand Visibility per Customer Group:  
• Client will provide details on which brands should be restricted for each customer group. 
• The client will add necessary permissions to access custom record for customer role. 
• Automatic Password Reset: 
• The implementer will create a mass update script to populate the custom field with the previous password change date on all customer records.