Lập kế hoạch chuyển sang Adobe Commerce không chỉ là xác định Products, Customers, Orders, Categories, CMS Pages, Blog Posts và Reviews có thể được di chuyển hay không. Câu hỏi lớn hơn là những bản ghi đó có hỗ trợ được mô hình vận hành doanh nghiệp mà Adobe Commerce phải đảm nhận sau khi chính thức vận hành hay không. Cấu trúc Products, phạm vi storefront, quan hệ B2B company, shared catalogs, nhóm Customers, Content Staging, quyền sở hữu inventory, URLs và các tích hợp đều làm thay đổi cách cần diễn giải dữ liệu nguồn.
Một Cửa hàng nguồn có thể có các bản ghi nhìn rất đầy đủ nhưng vẫn thiếu cấu trúc mà Adobe Commerce cần. Một bản ghi Customers có thể tồn tại nhưng không còn quyền đại diện cho company. Một bản ghi Products có thể tồn tại nhưng thiếu attribute set đúng, website assignment, quan hệ với child SKU hoặc quyền hiển thị qua shared catalog. Một page có thể được di chuyển nhưng mất thời điểm campaign, bản địa hóa hoặc ý nghĩa của route. Vì vậy, khi rà soát mô hình dữ liệu cần tập trung vào hành vi kinh doanh mà dữ liệu phải duy trì, không chỉ việc trường có tồn tại hay không.
Ý nghĩa dữ liệu trong Adobe Commerce bắt đầu từ mô hình vận hành doanh nghiệp
Adobe Commerce kế thừa phần lớn nền tảng dữ liệu của kiến trúc Magento, nhưng cách diễn giải khi chuyển đổi khác đi vì nền tảng thường được chọn cho hoạt động thương mại có nhiều yêu cầu quản trị hơn. Cùng một bản ghi thuộc Products, Customers hoặc Orders, hoặc cùng một page có thể phải tham gia vào cấu trúc nhiều storefront, mua hàng B2B, quy tắc phê duyệt, pricing theo nhóm Customers, quyền truy cập shared catalog, enterprise các tích hợp hoặc hoạt động content theo lịch.
| Nhóm dữ liệu | Cách cần hiểu trong Adobe Commerce | Hệ quả khi lập kế hoạch chuyển đổi |
|---|---|---|
| Products | Các loại Products, child SKUs, attributes, attribute sets, websites, Categories, prices, visibility và quan hệ inventory. | Dữ liệu catalog phải hỗ trợ cách bán hàng ở cấp doanh nghiệp, không chỉ hiển thị trên storefront. |
| Customers | Người mua cá nhân, nhóm Customers, company users, addresses, lịch sử đơn hàng và quyền của tài khoản. | Dữ liệu Customers có thể phải giữ cả danh tính lẫn ngữ cảnh mua hàng. |
| Companies | Company administrators, company users, roles, permissions, credit, quotes, Purchase Orders và trạng thái phê duyệt. | Cần xác định riêng dữ liệu B2B trước khi coi Customers là tài khoản thông thường. |
| Shared catalogs | Khả năng xem catalog và pricing theo từng người mua thông qua nhóm Customers hoặc gán company. | Một bản ghi Products tồn tại không có nghĩa mọi người mua đều được nhìn thấy bản ghi đó. |
| Phạm vi storefront | Websites, stores, store views, ngôn ngữ, currency, content, cấu hình và catalog assignment. | Dữ liệu nhiều thương hiệu, nhiều khu vực hoặc nhiều ngôn ngữ không được làm phẳng. |
| Content và campaigns | CMS Pages, CMS Blocks, scheduled updates, thời điểm promotions, landing pages và tài sản campaign. | Di chuyển nội dung tĩnh có thể không giữ được mục đích thương mại phụ thuộc thời gian. |
| Inventory | Sources, stocks, giả định về khả năng bán, channel assignment và quyền sở hữu tồn kho bên ngoài. | Quantity phải được đánh giá trong cấu trúc fulfillment, không chỉ theo số SKU. |
| URLs | URL keys, rewrites, redirects, đường dẫn bản địa hóa, custom routes và landing pages có giá trị cao. | Duy trì khả năng truy cập từ tìm kiếm phụ thuộc vào ý nghĩa route và phạm vi storefront, không chỉ việc page đã được chuyển. |
Câu hỏi thực tế là mỗi bản ghi có đủ cấu trúc để tiếp tục hoạt động trong Adobe Commerce hay không. Ngay cả một bản ghi được hỗ trợ vẫn có thể cần quan hệ đích khác, gán lại phạm vi, quyết định rõ về quyền sở hữu hoặc ranh giới triển khai nếu bản ghi đang mang theo quy tắc kinh doanh ở cấp doanh nghiệp.
Dữ liệu Products phụ thuộc vào loại Products, attributes và cách quản trị catalog
Di chuyển Products sang Adobe Commerce cần được diễn giải cẩn thận vì dữ liệu Products có thể ảnh hưởng đến cách storefront hoạt động, merchandising, filtering, search, pricing, inventory và các tích hợp. Loại Products là lớp ý nghĩa đầu tiên. Simple, Configurable, Grouped, Virtual, Bundle và Downloadable Products không hoạt động giống nhau. Một item ở nguồn có options có thể cần trở thành Configurable Products cùng các Simple Products liên kết. Một package hoặc kit ở nguồn cần được rà soát trước khi quyết định nên trở thành Bundle, Grouped Products, cần xử lý riêng hay không thuộc hành vi tiêu chuẩn.
Configurable Products đặc biệt quan trọng. bản ghi Products cha tạo ra một trải nghiệm sản phẩm thống nhất cho người mua, trong khi các Simple Products con mới mang ý nghĩa SKU thực sự có thể mua. Size, color, material, package size hoặc thông số kỹ thuật có thể quyết định SKU, price, image, inventory và identifiers phục vụ các tích hợp. Nếu những quan hệ này bị làm phẳng, catalog vẫn có thể trông đầy đủ nhưng mua hàng, fulfillment, báo cáo hoặc đồng bộ với ERP lại không hoạt động đúng.
Attributes và attribute sets bổ sung thêm yêu cầu quản trị. Attributes có thể quyết định các trường hiển thị, search, layered navigation, so sánh Products, hành vi import/export, điều kiện promotions, công việc bảo trì trong giao diện quản trị và các tích hợp. Attribute sets gom các nhóm Products vào những mẫu cấu trúc thống nhất. Một trường tùy chỉnh ở nguồn không nên tự động biến thành text trong phần mô tả nếu trường đó đang phục vụ filtering, pricing, đồng bộ PIM, search, báo cáo hoặc quy trình phía sau.
| Cấu trúc Products | Nội dung cần diễn giải | Vì sao quan trọng trong Adobe Commerce |
|---|---|---|
| Loại Products | Cấu trúc Simple, Configurable, Grouped, Bundle, Virtual, Downloadable hoặc yêu cầu xử lý riêng. | Loại Products quyết định cách người mua lựa chọn và mua Products. |
| Quan hệ child SKU | Quan hệ cha con, nhãn options, images, chênh lệch price, stock và identifiers. | Quan hệ sai có thể khiến Products hiển thị nhưng không thể sử dụng đúng cho hoạt động bán hàng. |
| Attributes | các trường hiển thị, các trường dùng cho search hoặc filtering, đầu vào cho rules, IDs phục vụ các tích hợp và các trường quản trị. | Quyết định về attributes ảnh hưởng đến quản trị catalog và khả năng tìm Products của người mua. |
| Attribute sets | Mẫu cấu trúc cho từng nhóm Products và các trường bắt buộc. | Lập kế hoạch attribute sets không tốt làm catalog khó bảo trì sau chuyển đổi. |
| Gán Categories | Navigation, merchandising, phạm vi storefront, visibility và cách URL hoạt động. | Hiểu sai ý nghĩa Categories có thể ảnh hưởng đến khả năng tìm Products, SEO và mức độ tin cậy của người mua. |
| Quan hệ giữa Products | Related Products, upsells, cross-sells, accessories, replacements và thông tin compatibility. | Mất quan hệ có thể làm giảm khả năng hỗ trợ quyết định mua và quy trình bán hàng. |
Mục tiêu không phải tái tạo từng trường ở nguồn theo cách một đối một. Cần giữ ý nghĩa thương mại của catalog dưới một cấu trúc Adobe Commerce có thể vận hành và quản trị, thay vì biến catalog đích thành kho lưu trữ các trường của hệ thống cũ.
Phạm vi storefront làm thay đổi ý nghĩa của bản ghi
Phạm vi storefront trong Adobe Commerce có thể làm thay đổi ý nghĩa của gần như mọi bản ghi sau chuyển đổi. Nền tảng nguồn có thể thể hiện thương hiệu, khu vực, ngôn ngữ, B2B portals, kênh bán lẻ, khu vực wholesale và storefront quốc tế qua Categories, domains, tags của Customers, markets, plugins hoặc các trường tùy chỉnh. Trong Adobe Commerce, những khác biệt đó có thể cần trở thành websites, stores, store views, cây Categories, nhóm Customers, shared catalogs, configuration rules hoặc các phiên bản content khác nhau.
Cần xác định phạm vi trước khi đi sâu vào mapping. Tên Products có thể dùng chung trong khi mô tả thay đổi theo store view. Một CMS Page có thể cần nhiều phiên bản bản địa hóa. Một bản ghi Products có thể thuộc một website nhưng không thuộc website khác. Đường dẫn Categories phù hợp với storefront bán lẻ có thể không phù hợp với private B2B catalog. Mức giá có thể phụ thuộc nhóm Customers hoặc quyền truy cập shared catalog thay vì chỉ phụ thuộc vào bản ghi Products.
Lỗi về phạm vi thường không lộ ra khi đếm bản ghi. Số Products, Categories, Customers hoặc pages dự kiến vẫn có thể được di chuyển đầy đủ trong khi một storefront nhận sai ngôn ngữ, price, Categories, visibility hoặc ngữ cảnh URL. Vì vậy, mô hình đích cần có cách gán rõ cho từng thương hiệu, khu vực, ngôn ngữ, website, store, store view, B2B segment và ngữ cảnh private catalog quan trọng.
Dữ liệu Customers có thể gồm cả danh tính cá nhân và quyền trong company
Trong Adobe Commerce, dữ liệu Customers có thể đại diện cho nhiều hơn danh tính của tài khoản cá nhân. Dữ liệu này có thể bao gồm nhóm Customers, quan hệ company account, company administrators, company users, permissions, quotes, Purchase Orders, company credit, payment methods, quy tắc shipping methods, địa chỉ pháp lý và gán shared catalog. Một bản ghi Customers có thể được chuyển đúng ở cấp tài khoản cá nhân nhưng kết quả vẫn thất bại nếu người mua mất quyền trong company hoặc quyền truy cập catalog.
Kế hoạch B2B cần tách danh tính Customers khỏi quyền mua hàng. Adobe Commerce liên kết tài khoản Customers tiêu chuẩn với Company accounts, và một Company có thể chứa administrator, teams, users, roles, permissions cùng các quan hệ phê duyệt. Email, address và lịch sử đơn hàng ở nguồn có thể đủ cho tài khoản B2C, nhưng để B2B tiếp tục hoạt động có thể còn cần danh tính company, địa chỉ pháp lý, gán administrator, cấu trúc tổ chức, trạng thái tài khoản, tax references, credit context và external account IDs.
| Thành phần trong cấu trúc Customers | Nội dung cần rà soát | Hệ quả khi chuyển đổi |
|---|---|---|
| Tài khoản cá nhân | Email, tên, địa chỉ, trạng thái, chiến lược password và liên kết Orders. | Người mua cần tiếp tục nhận diện được tài khoản của mình. |
| Nhóm Customers | Discount, tax, catalog, pricing hoặc cách xử lý theo storefront. | Gán sai group có thể ảnh hưởng trải nghiệm người mua và độ chính xác của Orders. |
| Company account | Company administrator, địa chỉ pháp lý, company users, cấu trúc phân cấp và trạng thái tài khoản. | Hoạt động mua hàng theo company có thể thất bại nếu chưa lập kế hoạch đúng cấu trúc company. |
| Kiểm soát mua hàng | Quotes, Purchase Orders, credit, payment methods, shipping methods và permissions. | Quy trình B2B có thể cần cấu hình hoặc triển khai riêng ở Cửa hàng đích ngoài các bản ghi Customers đã di chuyển. |
| External identifiers | ERP ID, CRM ID, dealer ID, account manager reference, contract ID hoặc tax reference. | Hệ thống bên ngoài có thể phụ thuộc vào identifiers không nhìn thấy khi chỉ rà soát storefront. |
Dữ liệu Company trong Adobe Commerce không nên được xem như một danh sách các trường thông thường của Customers. Đây là cấu trúc phục vụ mua hàng. Phạm vi phải tách identities và relationships có thể di chuyển khỏi company permissions, purchasing controls, credit behavior và các tích hợp bên ngoài cần triển khai riêng ở Cửa hàng đích.
Shared catalogs biến quyền truy cập Products thành dữ liệu theo từng người mua
Shared catalogs làm cho quyền nhìn thấy Products và pricing trong Adobe Commerce phụ thuộc vào từng nhóm người mua. Adobe Commerce có thể duy trì một public shared catalog và các custom shared catalogs được gán cho Company accounts. Một bản ghi Products có thể tồn tại trong catalog chính nhưng không thuộc mọi shared catalog; custom price có thể đúng với Company này nhưng sai với Company khác; và quyền đối với Categories có thể thay đổi khi Shared Catalog được sử dụng.
Nền tảng nguồn thường thể hiện cùng mục đích kinh doanh theo nhiều cách khác nhau: wholesale price lists, tags của Customers, dealer groups, hidden Categories, danh sách Products riêng, contract pricing, quy tắc từ ERP hoặc các trường tùy chỉnh. Khi chuyển đổi, cần diễn giải lại những cấu trúc này thay vì sao chép trực tiếp.
Để xác định shared catalog ở đích, cần trả lời bốn câu hỏi: companies nào được quyền truy cập, Products nào thuộc từng catalog, custom prices nào áp dụng và quyền đối với Categories hoặc visibility rules nào phải được thể hiện trong Adobe Commerce. Price lists, hidden Categories, dealer tags và ERP contract references ở nguồn là thông tin xác nhận quan hệ cần có, chứ không tự động tương đương với một shared catalog.
Orders mang theo ngữ cảnh thương mại, B2B và các tích hợp
Di chuyển Orders sang Adobe Commerce cần giữ lịch sử đủ hữu ích để tra cứu, nhưng không được tạo cảm giác mọi cách quy trình checkout hoạt động ở nguồn sẽ trở thành hành vi đang hoạt động trong Adobe Commerce. Lịch sử đơn hàng có thể chứa các dòng hàng, Products, quantities, discounts, taxes, shipping, billing, tham chiếu Customers, trạng thái đơn hàng, payment references, refunds, invoices, shipments, credit memos, Purchase Orders, quote references, ngữ cảnh company và external IDs.
Với cửa hàng B2B và doanh nghiệp, lịch sử đơn hàng có thể cần diễn giải thêm. Một đơn hàng ở nguồn có thể thuộc company chứ không chỉ thuộc tài khoản Customers cá nhân. Discount lịch sử có thể phản ánh contract price hoặc giá trong shared catalog. Payment method có thể phụ thuộc quy tắc company. Purchase Orders có thể mang ý nghĩa phê duyệt. Với đội ngũ hỗ trợ, ERP mã đơn hàng đôi khi còn quan trọng hơn mã đơn hàng trên storefront.
| Ngữ cảnh của Orders | Nội dung cần giữ hoặc phân loại | Vì sao quan trọng |
|---|---|---|
| Quan hệ Customers và company | Tài khoản người mua, company account, quan hệ administrator/user và ngữ cảnh group. | Đội ngũ hỗ trợ cần hiểu ai đã đặt đơn hàng và đặt dưới tài khoản nào. |
| Chi tiết tài chính | Subtotal, discounts, taxes, shipping, refunds, credit memos, invoices và payment references. | Lịch sử phải đủ rõ để phục vụ chăm sóc và đối soát. |
| Ngữ cảnh quy trình B2B | Quote, Purchase Orders, account credit, approval hoặc contract reference. | Ý nghĩa B2B trong lịch sử có thể không phải dữ liệu Orders thông thường. |
| Trạng thái fulfillment | Shipment, partial fulfillment, cancellation, return, warehouse reference hoặc ERP status. | Đội ngũ vận hành cần hiểu điều gì đã xảy ra sau giao dịch mua. |
| External identifiers | ERP ID của đơn hàng, accounting ID, marketplace ID, CRM opportunity hoặc warehouse reference. | Khả năng tiếp tục hoạt động của các tích hợp có thể phụ thuộc vào identifiers ngoài các trường chuẩn của Orders. |
Mô hình Orders ở đích phải tính đến các quan hệ khác nhau trong Orders B2C, Orders B2B, Orders có refund hoặc credit, Orders chịu ảnh hưởng của discount và tax, tham chiếu bên ngoài cùng ngữ cảnh company hoặc nhóm Customers. Chính những quan hệ này quyết định liệu lịch sử đơn hàng có còn dễ hiểu sau chuyển đổi hay không.
Content, campaigns và URLs cần được diễn giải riêng
Content trong dự án chuyển đổi sang Adobe Commerce có thể bao gồm CMS Pages, CMS Blocks, nội dung Categories, mô tả Products, landing pages, Blog Posts khi phù hợp, media, metadata và tài sản promotions. Với cửa hàng doanh nghiệp, content còn có thể gắn với thời điểm campaign, storefront theo khu vực, merchandising calendar, quản trị thương hiệu, rà soát pháp lý hoặc approval workflows.
Content Staging làm thay đổi cách cần hiểu content khi thời điểm có ý nghĩa. Adobe Commerce có thể lên lịch thay đổi cho Products, Categories, catalog và cart price rules, CMS Pages và CMS Blocks dưới các updates gắn với campaign. Landing page, banner Categories, promotion hoặc thay đổi price theo lịch có thể vẫn tồn tại dưới dạng content nhưng mất ý nghĩa thương mại nếu bị rút thành một bản ghi tĩnh. Vì vậy, phạm vi cần tách evergreen content, campaigns trong tương lai, scheduled changes đang hoạt động và tài sản của campaigns đã hết hạn.
URLs cũng cần được tách theo cách tương tự. URL keys của Products, URL keys của Categories, CMS paths, URL rewrites, localized paths, redirects và custom landing-page routes cần được rà soát theo giá trị kinh doanh. Số lượng pages có thể khớp trong khi các trang chi tiết Products quan trọng đối với traffic và SEO, đường vào B2B, dealer portals, URLs theo khu vực hoặc campaign pages lại mất khả năng truy cập như trước.
Dữ liệu do các tích hợp sở hữu phải được xác định trước khi mapping
Dự án chuyển đổi sang Adobe Commerce thường phụ thuộc vào ERP, PIM, CRM, OMS, WMS, hệ thống thuế, payment, shipping, marketplace, loyalty, subscription, analytics, search, personalization hoặc marketing. Những hệ thống này có thể sở hữu các trường và identifiers không dễ nhận ra khi chỉ nhìn storefront.
Ví dụ gồm ERP IDs cho Products, PIM IDs cho Products, company account IDs, dealer IDs, contract IDs, price-list references, warehouse stock codes, tax exemption IDs, CRM account references, marketplace item IDs, subscription IDs và mã đơn hàng trong hệ thống bên ngoài. Nếu các giá trị này bị xóa, đổi tên hoặc đặt vào trường không phù hợp, Cửa hàng đích có thể trông đúng trong khi quy trình phía sau lại thất bại.
Dữ liệu do các tích hợp sở hữu phải được phân loại trước khi chốt mapping từ nguồn sang đích. Một giá trị có thể thuộc native attribute, trường do extension sở hữu, key dùng chung giữa các hệ thống, payload riêng của các tích hợp hoặc cấu trúc legacy cần loại khỏi phạm vi. Quyết định phải theo hệ thống sẽ tiếp tục sở hữu giá trị sau chuyển đổi, không theo vị trí tình cờ mà giá trị được lưu ở Cửa hàng nguồn.
Quan hệ dữ liệu Adobe Commerce cần có kết quả sở hữu rõ ràng
Mô hình đích Adobe Commerce hoàn chỉnh phải xác định được người hoặc hệ thống sở hữu và ý nghĩa trên toàn bộ chuỗi quan hệ. Bản ghi Products phục vụ quản trị catalog; Customers và Companies giữ quyền mua hàng; Orders duy trì lịch sử đủ để hỗ trợ khách hàng; content có đúng ngữ cảnh storefront và campaign; URLs giữ đúng mục đích truy cập; còn các trường phục vụ các tích hợp vẫn truy nguyên được đến hệ thống tiếp tục sử dụng chúng.
Một lần rà soát dữ liệu hữu ích nên trả lời được:
- Products có thể được duy trì theo nhóm Products, attribute set, website và phạm vi storefront không?
- Người mua B2B có truy cập đúng catalog, price, account, quote, Purchase Orders và credit context không?
- Đội ngũ hỗ trợ có thể hiểu lịch sử đơn hàng cơ bản mà không phải quay lại hệ thống nguồn không?
- Content và URLs có hỗ trợ kế hoạch chính thức vận hành, duy trì khả năng truy cập từ tìm kiếm và yêu cầu campaign không?
- Các hệ thống bên ngoài còn nhận diện được những bản ghi đã di chuyển mà chúng phụ thuộc vào không?
Nếu chưa thể trả lời các câu hỏi này từ phạm vi đã xác định, quan hệ dữ liệu ở đích vẫn chưa được định nghĩa rõ dù các bản ghi nguồn đã sẵn sàng.
Kết luận
Adobe Commerce làm thay đổi cách lập kế hoạch chuyển đổi vì dữ liệu thường mang theo quy tắc vận hành ở cấp doanh nghiệp. Products không chỉ là items, mà còn là các loại Products, attributes, attribute sets, websites, store views, Categories, quan hệ inventory và tham chiếu các tích hợp. Customers không chỉ là hồ sơ, mà còn có thể gắn với Companies, users, administrators, nhóm Customers, quyền mua qua shared catalog và quy trình phê duyệt. Content, URLs, Orders và inventory cũng có thể phụ thuộc vào phạm vi, thời điểm và hệ thống bên ngoài.
Một dự án chuyển đổi sang Adobe Commerce được chuẩn bị tốt xem công việc mô hình dữ liệu như quá trình chuyển đúng ý nghĩa kinh doanh sang cấu trúc mới. Mục tiêu là đưa bản ghi vào cấu trúc có thể hỗ trợ quản trị catalog, mua hàng B2B, phạm vi storefront, duy trì content và quyền quản lý các tích hợp.
Câu hỏi thường gặp
Vì sao chuyển dữ liệu sang Adobe Commerce cần nhiều hơn liên kết các trường?
Nhiều bản ghi Adobe Commerce mang ý nghĩa vận hành, nên liên kết các trường đơn thuần chưa đủ. Products, Customers, Orders, content, URLs và inventory có thể ảnh hưởng đến mua hàng B2B, shared catalogs, phạm vi storefront, quản trị attributes và quyền quản lý các tích hợp.
Shared catalogs của Adobe Commerce khác Categories thông thường như thế nào?
Categories tổ chức navigation và merchandising của catalog. Shared catalogs có thể kiểm soát khả năng xem Products và pricing theo từng người mua, thường gắn với Companies hoặc nhóm Customers. Vì vậy, cần lập kế hoạch shared catalogs như quan hệ về quyền truy cập và giá, không chỉ như cấu trúc catalog.
Điều gì làm dữ liệu Customers phức tạp hơn trong Adobe Commerce?
Dữ liệu Customers có thể bao gồm tài khoản cá nhân, nhóm Customers, company accounts, company users, administrators, roles, credit, quyền sử dụng quotes, quyền Purchase Orders và gán shared catalogs. Một bản ghi Customers có thể được di chuyển đúng như tài khoản nhưng vẫn mất ý nghĩa mua hàng B2B.
Có nên xem dữ liệu Content Staging như content CMS thông thường không?
Không nên. Scheduled updates, content theo campaign, promotional pages và các thay đổi dành riêng cho thời điểm ra mắt cần được rà soát riêng. Một phần content có thể di chuyển như CMS content ổn định, trong khi thời điểm và hành vi phê duyệt có thể cần cấu hình Adobe Commerce hoặc xây dựng lại thủ công.
Khi nào dữ liệu Adobe Commerce cần cách xử lý riêng ở đích?
Cần cách xử lý di chuyển dữ liệu hoặc triển khai riêng ở Cửa hàng đích khi phạm vi có dữ liệu extension không được hỗ trợ, cấu trúc database tùy chỉnh, quan hệ company hoặc catalog ngoài chuẩn, external-system identifiers hoặc hành vi không có điểm đến tương ứng trong Adobe Commerce.
External identifiers nên được thể hiện trong Adobe Commerce như thế nào?
Chỉ nên giữ một external identifier khi ERP, CRM, PIM, hệ thống fulfillment, tax hoặc báo cáo vẫn tiếp tục phụ thuộc vào identifier đó. Cần xác định giá trị đó thuộc trường có sẵn của nền tảng, trường do extension sở hữu, tham chiếu các tích hợp hay key dùng chung giữa các hệ thống. Kết quả cần giúp nhân sự và hệ thống liên kết truy nguyên được bản ghi sau chuyển đổi mà không biến identifier thành nội dung storefront hoặc nhầm identifier đó với Adobe Commerce ID của đối tượng dữ liệu.