C-008 Item Master D365 to NS

Diversified NetSuite + OpenAir Implementation C-008 Item Master D365 to NetSuite Date Written: October 18, 2023 Author: Linda White Conversion ID: C-008 ADO Item: 1694 1 | P a g e

Document Information Authors Linda White Contributors Below Supply Chain CPQ/Engineering Finance Sales Diane Phipps Andy Bennett Lisa Campbell Nick Mitchell Steven Speights Russell Townshend Dawna Eldringhoff Mary Keuffer Maddy Sheikhalizadeh Bill Johnson Jr. Thomas Tallie Stu Zerneri Mark Dierks History Versio n Date Modified by Changes 1.0 10/27/202 3 LMW Initial 2.0 10/30/202 3 Item Master Team Changes to various fields Document Review and Sign-off Name Role Action Date Reviewed 2 | P a g e

1. Summary of the Data Conversion The scope of this document is to provide a solution for data required for the item master conversion. This document will identify the approach of 1) what will be moved from D365, 2) what data will need to be transformed, 3) how we will transform the data and 4) what technical logic is required for converting the legacy data, and 5) what groups will be responsible for providing the field data not currently existing in D365. This document should be used in SUPPLEMENT to the mapping document found on the Teams site. Shown below is a summary of our identified challenges with this conversion: 1.1. Limited Data Within 365 In general, from a functional perspective, the setup of D365 item is basic. Since we are taking advantage of more functionality within NS, there are multiple fields that will require logic and manual selection via the mapping document to populate the fields required for this solution. As it stands, only 14 fields (25%) of the fields identified from D365 can be transferred into NS, and of those, there are multiple fields requiring scrubbing and transformation. We need to ensure there is ample time for the extraction, cleansing and transforming of the data. 25% 56% 12% 7% Scope and Source of Field Data D365 Logic Logic and manual override Mapping file 4 | P a g e

Note: This table does not represent the level of effort (time) required per field data. 1.2. D365 Volume of Records The D365 volume of records (500K) is a high number. We have worked through the design to determine the best approach possible to convert the data required. We believe, based on our selection criteria, that the count of records migrated will be about 10% of the current item count in D365 today. Our approach is defined in section 2 of this document. 1.3. Transformation of Data The transformation of the data from the legacy system will prove challenging for the following reasons: 1.3.1. The GL account structure is changing from D365 to NS. The finance requirements to drill further down into the COGS (Cost of Goods Sold) results in the inability to convert the item data based solely on item group. We must transform the items into cost categories to define the GL postings. See section 3.3.3 for the new categorization of items. 1.3.2. D365 contains item numbers that are serialized which should not be in the future state solution. This step will include scrubbing of the data and will affect C-024 which is the import of inventory on-hand. 1.3.3. Currently we have inventory on-hand for items that are non-tangible in nature. We will need to transform this data. This will be included in C-024 as well. 1.3.4. The quality of the data is in question. Based on a data sampling from D365, we saw items categorized incorrectly and multiple duplicate records. While there were reasons for this, the team has concluded that the data we move to NS will require significant review. 1.3.5. ConnectWise conversion is happening independently. The final list of D365 items will need to be deduped with the ConnectWise items (C-009). In summary, our intent, by approval of this document, is to provide the technical resources everything they need for a smooth transition of the item master data from the legacy system and other defined sources and methods. For the reasons listed in section 1.3, this conversion will require tweaks to this solution once we are more familiar with the data from the legacy system. 5 | P a g e

_TrackingDimenisonGroup = "SERIAL” for Inventory Item-Serial AND 6: EcoResProduct_ProductTypeTitle="ITEM" The concatenation of this criteria will provide the list of items for potential migration to NS. 2.1. Field Data Analysis 2.1.1. Fields that can be migrated from D365. The mapping of these NS fields can be found in the conversion mapping document referenced on page 2 of this document. Shown below is the high-level analysis. 3. Cleansing Considerations 3.1.Serialization analysis 3.1.1. Note: There will be no separate upload of serialized numbers to item number association table as this is not needed in NS (can be added to serial number table on the fly). Serialization per item number will be deferred to the C-024 conversion. 3.2.Duplication analysis 3.3.Item Category analysis (see section 4.3.3) 3.4.Item Data (MFR, Part Number, Description) analysis 3.5.Procurement category analysis 4. Entity, field, and customization dependencies 4.1.The following data entities are required to be populated prior to the import of items: 4.1.1. Vendors 4.2.The following WRICEF items must be completed prior to the import of items: 4.2.1. F-006 Item Master Form Changes – Since our solution involves custom forms for all item types in usage and we are storing the custom form on the item record, this setup/configuration must be complete prior to the import of items. 4.2.2. F–011 Item Master Additional Fields – New fields must be configured in the system before importing items. 7 | P a g e

4.2.3. F-012 End of Life Field on Item Master Form – This customization has not been solutioned yet. Based on the final solution, we will add a default to any newly created fields. 4.3.The following field lists must be configured prior to the import of items: 4.3.1. Units of Measure 4.3.2. Unit Conversion Table - D365 conversion table and functionality is not set up properly and therefore is causing cost issues. The items requiring conversion must be determined and a manual entry of the correct primary stock, purchase, and sale unit must be corrected. 4.3.3. Cost Category – The cost category will be used in the logic for the conversion of data specified above for certain fields. Shown below is the mapping source for cost category to revenue and COGS accounts. Variation Item Type Cost Category Income Account COGS Account Asset Account 1A Inventory Item/Serial Material 40005 50003 12150 1B Inventory Item/Serial Equipment 40005 50002 12100 1C Inventory Item/Serial Software (Tangible) 40099 50041 12200 2A Non-Inventory – For Resale Software (Intangible) 40099 50041 - 2B Non-Inventory – For Resale Software Licensing 40099 50042 - 2C Non-Inventory – For Resale Connectivity – Client (Broadband) 40099 50045 - 3A Other Charge – For Resale Rental Equipment Expense 40005 50009 - 3B Other Charge – For Resale Freight In 40090 50191 - 3C Other Charge – For Resale Freight Out 40090 50192 - 3D Other Charge – For Resale Travel 40030 50030 - 4A Non-Inventory – For Purchase Shipping/Packaging Materials 50196 - 5A Service Item – For Resale Direct Labor 40010 50012 - 5B Service Item – For Resale Subcontractor Labor 40010 50022 - 5C Service Item – For Resale Mfg. Commissioning/Training 40010 50023 - 5D Service Item – For Resale Sub Coverage (extended warranty) 40010 50024 - 5E Service Item – For Resale Satellite Programming (Dish) 40010 50046 - 4.3.3.1. Tax Code Logic 8 | P a g e

4.3.3.2.1. COGS Account – By cost category and illustrated above. 4.3.3.2.2. Intercompany COGS Account – Out of scope 4.3.3.2.3. Asset Account – By cost category and illustrated above. 4.3.3.2.4. Income Account – By cost category and illustrated above. 4.3.3.2.5. Intercompany Income Account – Out of scope 4.3.3.2.6. Deferred Revenue Account – Default to 20410 4.3.3.2.7. Intercompany Deferred Revenue Account – Out of scope 4.3.3.2.8. Gain/Loss Account – Default to 50116 4.3.3.2.9. Price Variance Account – Out of scope 4.3.3.2.10. Quantity Variance Account – Out of scope 4.3.3.2.11. Exchange Rate Variance Account – Out of scope 4.3.3.2.12. Customer Return Variance Account – Out of scope 4.3.3.2.13. Vendor Return Variance Account – Out of scope 4.3.3.2.14. Purchase Price Variance Account – Default to 50111 4.3.3.2.15. Dropship Expense Account – Out of scope 4.3.3.2.16. Project Expense Type (on service for resale item type) 10 | P a g e

4.3.3.2.17. VSOE Price – Out of scope 4.3.3.2.18. Allocation Type - 4.3.3.2.19. Permit Discount - 4.3.3.2.20. Default as Delivered - 4.3.3.2.21. Item Revenue Category - 4.3.3.2.22. Hold Revenue Recognition - 4.3.3.2.23. Revenue Recognition Rule - 4.3.3.2.24. Rev Rec Forecast Rule - 4.3.3.2.25. Revenue Allocation Group - 4.3.3.2.26. Create Revenue Plans On - 4.3.3.2.27. Direct Revenue Posting - 4.3.3.2.28. Eligible For Contingent Revenue Handling - 4.3.3.2.29. Foreign Currency Adjustment Account – Out of scope at this time 4.3.4. Chart of Accounts – must be loaded and finalized prior to the import of items. 4.3.5. Tax Schedule – The tax schedule/Avalara setup must be finalized prior to the import of items. 5. Unit Testing and Validation 5.1.Record-level verification 5.1.1. Verify the count of records from source data produced a record in the destination. 11 | P a g e