Khi lập kế hoạch mô hình dữ liệu cho VTEX, câu hỏi đầu tiên không nên là có thể sao chép được bao nhiêu trường, mà là: bản ghi nào ở Cửa hàng nguồn sẽ trở thành cấu trúc thương mại có thể sử dụng trong VTEX, và bản ghi nào thực chất thuộc một miền VTEX khác, phần triển khai storefront, kết nối tích hợp hoặc hệ thống bên ngoài? VTEX là môi trường thương mại mô-đun, vì vậy ý nghĩa dữ liệu được phân bổ giữa Catalog, SKUs, specifications, hệ thống giá, promotions, checkout, Orders, logistics, sellers, ngữ cảnh marketplace, Master Data, search, storefront và các hệ thống liên quan.
Điểm này làm VTEX khác với nền tảng nơi Products, Customers, Orders, pages và URLs có thể được rà soát phần lớn như những bản ghi riêng lẻ. Một option của Products ở nguồn có thể cần trở thành SKU, specification, lựa chọn trên storefront, trường tùy chỉnh hoặc một yêu cầu phải xây dựng lại. Một trường Customers ở nguồn có thể chỉ là thông tin profile, nhưng cũng có thể thuộc Master Data, B2B, CRM hoặc metadata của kết nối tích hợp. Một bản ghi Orders ở nguồn có thể tiếp tục có giá trị cho hỗ trợ khách hàng, nhưng lịch sử đó không tự cấu hình Checkout, payment, quy trình hoàn tất đơn hàng, marketplace hay logistics của VTEX.
Phạm vi chuyển đổi mạnh nhất không phải phạm vi di chuyển nhiều nhất. Phạm vi tốt là phạm vi giữ đúng ý nghĩa cần sử dụng của dữ liệu, đồng thời tách rõ bản ghi được di chuyển khỏi cấu hình VTEX, phần triển khai front-end, quyền sở hữu của các tích hợp, mapping có cấu trúc hoặc cách xử lý riêng trên Nền tảng đích, và những yêu cầu cần tái cấu trúc theo mô hình mới.
Ý nghĩa dữ liệu của VTEX được phân bổ giữa nhiều dịch vụ thương mại
Mỗi nhóm dữ liệu cần được diễn giải theo miền VTEX sẽ chịu trách nhiệm sau chuyển đổi. Dữ liệu Catalog có thể ảnh hưởng đến phần hiển thị Products, search, giá, promotions, khả năng bán của SKU, logistics và marketplace. Lịch sử đơn hàng có thể quan trọng cho hỗ trợ và báo cáo, nhưng cách xử lý đơn hàng đang hoạt động phụ thuộc vào Checkout, payment, quy trình hoàn tất đơn hàng, logistics và cấu hình vận hành. Dữ liệu Customers có thể trông đơn giản lúc đầu nhưng Master Data, segmentation, B2B, identifiers trong CRM hoặc forms tùy chỉnh lại tạo ra các quyết định khác nhau.
Mô hình phân tán này thay đổi cách rà soát chuyển đổi. Một trường được xem là attribute thông thường của Products ở nguồn có thể trở thành specification trong VTEX. Một variant có thể cần cấu trúc ở cấp SKU. Giá theo kênh có thể thuộc hệ thống giá hoặc price tables thay vì bản ghi Products. Tham chiếu seller trên marketplace có thể không phải dữ liệu Catalog thông thường. Một trang nội dung có thể cần triển khai trong storefront hoặc lập kế hoạch redirect thay vì di chuyển một-một.
| Bản ghi hoặc cách hoạt động ở nguồn | Câu hỏi cần đặt khi chuyển sang VTEX | Ý nghĩa đối với chuyển đổi |
|---|---|---|
| Option hoặc variant của Products | Đây là SKU có thể bán, specification của Products hay lựa chọn chỉ tồn tại trên storefront? | Quan hệ Products-SKU-specification phải được xác định rõ trong phạm vi. |
| Attribute hoặc trường tùy chỉnh | Trường này dùng cho filtering, mô tả Products, vận hành, tích hợp hay workflow Customers? | Mapping phụ thuộc vào mục đích kinh doanh, không chỉ vào tên trường giống nhau. |
| Giá hoặc promotion theo kênh | Đây là giá cơ sở, price table, điều kiện theo sales channel, mã giảm giá hay quy tắc promotion đang hoạt động? | Cần tách cách hoạt động thương mại hiện tại khỏi dữ liệu giá lịch sử. |
| Trường bổ sung của Customers | Đây là dữ liệu profile, Master Data, ngữ cảnh B2B, metadata CRM hay thông tin do tích hợp quản lý? | Một số giá trị có thể cần mapping/filtering trong phạm vi hỗ trợ, tái cấu trúc riêng hoặc tiếp tục do hệ thống bên ngoài xử lý. |
| Status của Orders hoặc ghi chú hoàn tất đơn hàng | Đây là thông tin về giao dịch trước đây phục vụ hỗ trợ hay là cách OMS/logistics cần vận hành trực tiếp? | Di chuyển Orders không nên bị xem là cấu hình workflow của hệ thống đích. |
Do đó, VTEX đòi hỏi mapping theo ý nghĩa. Mỗi nhóm dữ liệu cần có mục đích và chủ thể chịu trách nhiệm trong tương lai; chính trách nhiệm đó quyết định dữ liệu sẽ nằm trong bản ghi được di chuyển, cấu hình VTEX, storefront, dữ liệu tích hợp, mô hình đích được tái cấu trúc hay phần loại khỏi phạm vi có chủ đích.
Diễn giải Catalog bắt đầu từ quan hệ Categories, Brands, Products, SKUs và specifications
VTEX Catalog không phải một bảng Products phẳng. Cấu trúc cốt lõi liên kết Categories, Brands, Products, SKUs và specifications. Products thể hiện định nghĩa thương mại chung của mặt hàng, còn SKU thể hiện biến thể hoặc đơn vị vật lý có thể quản lý tồn kho và mua. Các specification groups gắn với Categories xác định những thuộc tính Products/SKU nào được áp dụng và có thể được kế thừa xuống các cấp Categories.
| Cấu trúc ở nguồn | Cách diễn giải trong VTEX | Hệ quả đối với quan hệ dữ liệu |
|---|---|---|
| Products cha cùng các variants con | Products với một hoặc nhiều SKUs | Danh tính có thể bán, images, inventory và dòng chi tiết trong Orders cần thuộc cấp SKU khi phù hợp. |
| Attribute của Products | Specification ở cấp Products | Giữ ý nghĩa của trường và giá trị gắn với Categories thay vì biến mọi thứ thành free text. |
| Attribute của variant như size hoặc voltage | SKU specification | Giữ attribute gắn với SKU đại diện cho biến thể vật lý. |
| Brand hoặc manufacturer | Quan hệ Brand | Không làm phẳng giá trị khi navigation hoặc khả năng tìm thấy Products phụ thuộc vào Brand. |
| Cây Categories | Phân loại Catalog | Vị trí trong Categories ảnh hưởng đến kế thừa specifications và cách Products được tổ chức. |
| Bộ images của Products | Quan hệ media ở cấp SKU | Cách Products có thể bán và hiển thị images phải còn gắn với đúng SKUs đang hoạt động. |
| Bundle, kit hoặc cấu trúc lắp ghép tùy chọn | Kit, attachment, assembly option, service hoặc cách xử lý bên ngoài | Cần xác định cấu trúc VTEX nào thực sự sở hữu các thành phần và quan hệ giá. |
Dự án có thể giữ lại toàn bộ tên Products nhưng vẫn tạo ra Catalog yếu nếu SKUs, specifications, images, Categories và Brands không còn mô tả cùng một đơn vị thương mại có thể bán.
Specifications, attachments và assembly options giữ những ý nghĩa khác nhau
Specifications trong VTEX là thuộc tính có cấu trúc gắn với Categories và áp dụng ở cấp Products hoặc SKU. Chúng có thể phục vụ navigation, so sánh, lựa chọn, tích hợp hoặc hiển thị. Vì vậy, mục đích của specification quan trọng không kém giá trị. Trường “color” dùng cho filtering không tự tương đương với ghi chú màu dạng văn bản; size dùng để phân biệt SKUs cũng không giống một thông số kích thước mô tả ở cấp Products.
VTEX còn tách specifications khỏi các cấu trúc tùy chọn khác. Attachments có thể thu thập thông tin gắn với SKU. Assembly options có thể biểu diễn tổ hợp phức tạp hơn về thành phần, số lượng, items bổ sung, chi phí và quan hệ tồn kho. Kits nhóm các SKUs được bán cùng nhau; phần dịch vụ tính phí có thể được biểu diễn qua quan hệ service ở cấp SKU. Những khái niệm này không nên bị gom vào một cột “option” chung.
| Ý nghĩa ở nguồn | Khái niệm đích trong VTEX | Điểm khác biệt cần giữ |
|---|---|---|
| Đặc điểm mô tả | Specification ở cấp Products | Mô tả đặc điểm chung ở cấp Products. |
| Đặc điểm tạo ra variation | SKU specification | Phân biệt đơn vị có thể bán. |
| Thông tin do người mua cung cấp | Attachment | Bổ sung thông tin cho SKU mà không nhất thiết tạo SKU khác. |
| Thành phần hoặc tổ hợp có thể cấu hình | Assembly option | Biểu diễn items bổ sung, số lượng, chi phí hoặc quan hệ tồn kho. |
| Nhóm đơn vị có thể bán | Kit | Giữ cấu trúc nhiều SKUs được bán cùng nhau. |
| Phần dịch vụ tính phí gắn với mặt hàng | Quan hệ service của SKU | Giữ phần bổ sung tách khỏi danh tính SKU cơ sở. |
Mô hình đích cần duy trì cấu trúc chi phối danh tính Products, lựa chọn của khách hàng, inventory và cách diễn giải chi tiết mặt hàng trong Orders, chứ không chỉ giữ lại nhãn và giá trị.
Giá, promotions, trade policies và offers là những lớp thương mại riêng
Bản export ở nguồn có thể đặt giá, sale price, channel, marketplace và trạng thái khả dụng cạnh bản ghi Products. VTEX tách các ý nghĩa này ra giữa Catalog, hệ thống giá, Promotions, trade policies, logistics, inventory và seller offers. Vì vậy, cùng một SKU có thể tham gia nhiều ngữ cảnh thương mại khác nhau mà không cần trở thành nhiều Products.
| Bản ghi thương mại | Ý nghĩa trong VTEX | Hệ quả về quyền sở hữu |
|---|---|---|
| Giá cơ sở hoặc giá niêm yết | Quan hệ giá của SKU | Giá không phải attribute cố định của Products. |
| Kết quả promotion hoặc mã giảm giá | Điều chỉnh thương mại do rule quyết định | Dữ liệu discount trong Orders trước đây khác với promotion rules đang hoạt động. |
| Trade policy | Ngữ cảnh sales channel | Quyết định Products/SKUs được bán ở đâu và có thể kết nối các điều kiện thương mại khác. |
| Inventory và logistics | Khả năng cung ứng và cam kết hoàn tất đơn hàng | Tồn kho và ý nghĩa giao hàng nằm ngoài bản ghi Catalog mô tả. |
| Seller offer | Offer thương mại của seller cho một mặt hàng trong Catalog | Danh tính marketplace và quyền sở hữu seller phải tách khỏi định nghĩa Products. |
| Nhóm Products theo kênh | Khả năng bán Products theo trade policy hoặc seller | Giữ quan hệ theo kênh thay vì nhân bản Products. |
Mô hình nhiều lớp đặc biệt quan trọng khi Cửa hàng nguồn dùng catalog theo khu vực, price lists B2B, marketplace offers hoặc giá do ERP quản lý. Dự án cần giữ identifiers nối SKU với giá, kênh, seller, inventory và dữ liệu logistics tương ứng.
Customers, dữ liệu B2B và Master Data cần danh tính rõ ràng
Dữ liệu liên quan đến Customers trong VTEX có thể trải rộng từ shopper profiles, addresses, cấu trúc tổ chức B2B, identifiers trong CRM, consent records, forms tùy chỉnh đến Master Data documents. Master Data là cơ sở dữ liệu key-document gốc của VTEX, có thể lưu, tìm kiếm, mở rộng và cá nhân hóa dữ liệu; vì vậy một bản ghi tùy chỉnh có thể là đối tượng vận hành độc lập chứ không chỉ là trường bổ sung của Customers.
| Bản ghi ở nguồn | Chủ thể có thể chịu trách nhiệm trong VTEX | Câu hỏi về danh tính |
|---|---|---|
| Shopper profile | Dữ liệu Customers hoặc profile | Email, document hoặc external key nào đại diện cho người này? |
| Address | Bản ghi address liên quan đến Customers | Đây là dữ liệu tài khoản có thể dùng lại, snapshot trong một đơn hàng hay cả hai? |
| Company, organization, buyer role hoặc cost center | Miền B2B hoặc mô hình dữ liệu tùy chỉnh | Quan hệ nào kiểm soát quyền truy cập, phê duyệt, Catalog hoặc ngữ cảnh giá? |
| Giá trị loyalty, CRM hoặc qualification | Master Data hoặc CRM bên ngoài | Hệ thống nào cập nhật giá trị và key nào nối giá trị đó với Customers? |
| Dữ liệu gửi qua form tùy chỉnh | Master Data document | Đây là thuộc tính của Customers, bản ghi workflow hay một đối tượng độc lập? |
| Marketing consent | Quan hệ Customers hoặc hệ thống marketing | Giữ mục đích, thời điểm, nguồn và ý nghĩa pháp lý khi cần thiết. |
Việc đưa mọi dữ liệu bổ sung vào Customers sẽ làm mất cấu trúc nếu thực tế dữ liệu mô tả organizations, approvals, service requests hoặc đối tượng nghiệp vụ khác. Điều quan trọng là giữ đúng danh tính và liên kết bền vững giữa các đối tượng.
Lịch sử đơn hàng không cấu hình Checkout, Payments, OMS hoặc Logistics
Orders lưu kết quả của giao dịch đã xảy ra. Mỗi bản ghi Orders có thể chứa items, SKUs, seller, prices, discounts, payment information, shipping result, addresses, package data, invoices, status history, cancellation/refund context và external identifiers. Những dữ liệu này có giá trị cho hỗ trợ khách hàng, finance, marketplace operations và báo cáo.
Tuy nhiên, các dữ liệu lịch sử không tự cấu hình cách hệ thống xử lý Orders mới. Checkout, Payments, OMS, inventory, logistics, sellers, pickup, shipping, taxation và các tích hợp cần cấu hình hoặc kết nối đang hoạt động riêng.
| Dữ liệu lịch sử của đơn hàng | Giá trị sau chuyển đổi | Không tự thiết lập |
|---|---|---|
| Items và SKUs đã mua | Thông tin xác nhận mặt hàng và biến thể khách hàng đã mua | Catalog hoặc SKU đang hoạt động |
| Price, discounts và payment result | Bối cảnh tài chính của giao dịch cũ | Price tables, promotions hoặc payment methods đang hoạt động |
| Tham chiếu giao dịch payment | Thông tin xác nhận quá trình xử lý payment | Cấu hình gateway và antifraud đang hoạt động là lớp riêng |
| Shipping result và address | Cam kết giao hàng trong quá khứ | Logistics, docks, warehouses, carriers hoặc pickup points hiện tại |
| Status và dữ liệu hoàn tất đơn hàng | Trạng thái OMS trong quá khứ | Workflow xử lý Orders mới |
| ID đơn hàng bên ngoài | Dòng liên kết giữa các hệ thống | Giữ lại nếu ERP, marketplace, hỗ trợ khách hàng hoặc báo cáo vẫn dùng identifier này |
Ranh giới cần giữ là mô hình quan hệ: giá trị lịch sử nào phải tiếp tục gắn với Orders, và miền vận hành nào sẽ sở hữu cách hoạt động trong tương lai.
Catalog marketplace, sellers và offers cần quyền sở hữu riêng
VTEX có thể vận hành như marketplace, seller hoặc một phần của mạng marketplace kết nối. Vì vậy, dữ liệu marketplace không chỉ bao gồm Products và Orders mà có thể gồm seller identities, seller SKUs, catalog matches, offers, prices, inventory, commissions, trách nhiệm hoàn tất đơn hàng, mapping Products/Categories và external listing references.
| Lớp marketplace | Ý nghĩa | Quan hệ cần giữ |
|---|---|---|
| Products và SKU chuẩn trong Catalog | Danh tính Catalog dùng chung | Seller offers phải tham chiếu đúng mặt hàng Catalog. |
| Seller | Chủ thể thương mại và vận hành | Giữ seller tách biệt với Brand, supplier hoặc manufacturer. |
| Offer | Giá, inventory và ngữ cảnh hoàn tất đơn hàng riêng của seller | Không hợp nhất tất cả offers vào định nghĩa Products. |
| Catalog mapping | Quan hệ giữa Products/Categories bên ngoài và VTEX | Giữ mapping key nếu connector tiếp tục hoạt động. |
| Nguồn marketplace của Orders | Lịch sử kênh và seller | Giữ nếu hỗ trợ khách hàng, settlement hoặc reporting phụ thuộc vào nguồn này. |
| Commission hoặc settlement reference | Ngữ cảnh tài chính marketplace | Giữ trong hệ thống sở hữu settlement thay vì ép vào trường Orders thông thường. |
Dự án chuyển sang VTEX cần xác định mỗi bản ghi marketplace ở nguồn sẽ trở thành quan hệ Catalog trong VTEX, seller offer, bản ghi connector bên ngoài, thuộc tính lịch sử của Orders hay đối tượng tiếp tục được lưu ở hệ thống khác.
Storefront, Trang Hệ thống quản lý nội dung, Blog Posts, search và URLs cần tách khỏi dữ liệu cốt lõi
Phần triển khai storefront VTEX có thể bao gồm frontend Headless, CMS components, search, merchandising, redirects và duy trì SEO. Products có thể đã được di chuyển vào VTEX trong khi trải nghiệm storefront vẫn chưa hoàn chỉnh. Một Trang Hệ thống quản lý nội dung có thể có giá trị nội dung nhưng không có quan hệ một-một với cách storefront đích được triển khai. Blog Posts có thể quan trọng đối với traffic tự nhiên, nhưng cách xử lý phụ thuộc vào phạm vi dữ liệu và cấu trúc nền tảng đích.
Khi lập kế hoạch mô hình dữ liệu, nội dung và URLs nên được đánh giá theo vai trò kinh doanh chứ không chỉ theo loại bản ghi. URL Categories ở nguồn có thể là đường dẫn Catalog, landing page cho search, trang merchandising hoặc tài sản SEO. Trang nội dung có thể là policy page, buying guide, campaign landing page hoặc custom layout. Search rule có thể thuộc chức năng sẵn có của nền tảng, app hoặc phần triển khai tùy chỉnh.
| Tài sản ở nguồn | Câu hỏi cần trả lời khi lập kế hoạch VTEX |
|---|---|
| URL của Products | Cần redirect, duy trì trang tương ứng hay xây lại theo routing của storefront? |
| Trang Categories hoặc collection | Đây là tổ chức Catalog, navigation, trải nghiệm search, nội dung SEO hay merchandising? |
| Trang Hệ thống quản lý nội dung | Cần di chuyển nội dung, dựng lại trong storefront, redirect hay loại bỏ? |
| Blog Posts | Thuộc phạm vi di chuyển dữ liệu, phạm vi SEO, chiến lược nội dung hay quyết định CMS riêng? |
| Quy tắc search/filter | Được quyết định bởi specifications, search configuration, app hay phần triển khai tùy chỉnh? |
Tách những lớp này giúp tránh việc Catalog bị coi là đã hoàn tất trong khi khả năng khách hàng tìm thấy Products, nội dung và quan hệ URLs vẫn chưa được giải quyết.
Hệ thống bên ngoài và dữ liệu tùy chỉnh xác định ranh giới thực sự của dự án
Chuyển đổi sang VTEX thường liên quan đến ERP, CRM, PIM, OMS, WMS, marketplace middleware, payment providers, loyalty systems, tax systems, analytics, công cụ hỗ trợ khách hàng và storefront applications tùy chỉnh. Những hệ thống này có thể sở hữu identifiers Products, giá, inventory, attributes Customers, tham chiếu Orders, seller data, dữ liệu hoàn tất đơn hàng hoặc các bản ghi tùy chỉnh.
Phạm vi dự án phải xác định hệ thống chịu trách nhiệm. Nếu ERP sẽ ghi đè một giá trị ở nguồn, giá trị đó chỉ cần được giữ nếu đóng vai trò trạng thái ban đầu, tham chiếu lịch sử hoặc reconciliation key. Nếu external ID phải tiếp tục nối Orders, Customers hoặc Products giữa nhiều hệ thống, việc giữ identifier có thể là yêu cầu trọng yếu. Nếu một bản ghi tùy chỉnh hỗ trợ workflow mà VTEX không biểu diễn bằng dữ liệu thương mại tiêu chuẩn, có thể cần mapping hoặc tái cấu trúc riêng.
| Loại dữ liệu bên ngoài hoặc tùy chỉnh | Quyết định về phạm vi |
|---|---|
| ID Products hoặc Orders từ ERP | Giữ nếu cần cho đối chiếu hoặc đồng bộ. |
| Attribute set từ PIM | Chỉ mapping các giá trị cần cho Catalog, specifications hoặc search của VTEX. |
| Identifier Customers từ CRM | Giữ nếu workflow hỗ trợ khách hàng hoặc marketing phụ thuộc vào identifier này. |
| Tham chiếu WMS hoặc quy trình hoàn tất đơn hàng | Xác định đây là dữ liệu lịch sử, cấu hình tích hợp hay yêu cầu xử lý riêng. |
| Dữ liệu app hoặc middleware | Rà soát khả năng xử lý được hỗ trợ trước khi giả định dữ liệu có thể được chuyển. |
Mapping hoặc filtering trong phạm vi được hỗ trợ có thể phù hợp khi yêu cầu liên quan đến dữ liệu được hỗ trợ. Cần xem xét mapping hoặc tái cấu trúc riêng khi yêu cầu liên quan đến dữ liệu không được hỗ trợ, bản ghi tùy chỉnh, phép biến đổi riêng, xử lý Nền tảng nguồn tùy chỉnh hoặc điều chỉnh cách di chuyển dữ liệu vượt ngoài chức năng tiêu chuẩn.
Ranh giới quyền sở hữu xác định phạm vi chuyển đổi VTEX
Phạm vi chuyển đổi VTEX được quyết định bởi quyền sở hữu và quan hệ dữ liệu, không phải số lượng bản ghi. Catalog nhỏ vẫn có thể phức tạp nếu phụ thuộc vào kế thừa specifications, assembly options, nhiều trade policies, sellers, Master Data documents hoặc external identifiers. Catalog lớn có thể tương đối đơn giản nếu Products, SKUs, Categories, Brands và specifications tuân theo một mô hình nhất quán.
| Mẫu dữ liệu ở nguồn | Câu hỏi cốt lõi | Hệ quả đối với phạm vi |
|---|---|---|
| Products có nhiều biến thể có thể mua | Đối tượng nào ở nguồn sẽ trở thành SKU trong VTEX? | Giữ Products cha, danh tính SKU, specifications, images và inventory references. |
| Nhóm Products theo khu vực hoặc B2B | Trade policy, giá và quan hệ truy cập nào áp dụng? | Tách ngữ cảnh thương mại khỏi danh tính Products. |
| Bảng Customers hoặc workflow tùy chỉnh | Bản ghi là profile, Master Data document, đối tượng B2B hay đối tượng của hệ thống ngoài? | Mô hình hóa đối tượng và quan hệ bền vững thay vì thêm tùy ý trường Customers. |
| Catalog marketplace | VTEX là marketplace, seller hay cả hai? | Tách bản ghi Catalog chuẩn khỏi seller offers và mapping keys. |
| Nội dung storefront Headless hoặc tùy chỉnh | CMS, app hoặc repository nào sở hữu nội dung? | Không coi phần triển khai storefront là dữ liệu Catalog thông thường. |
| Tích hợp ERP/PIM/WMS/OMS | Hệ thống nào là nguồn chính thức cho từng giá trị? | Giữ cross-system IDs và quy tắc sở hữu mà không sao chép toàn bộ mô hình bên ngoài. |
Ranh giới này giúp mô hình VTEX nhất quán giữa Catalog, dữ liệu thương mại, Customers, marketplace, nội dung và các miền vận hành.
Kết luận
VTEX phân bổ ý nghĩa thương mại giữa nhiều miền có liên hệ với nhau. Categories, Brands, Products, SKUs và specifications tạo thành Catalog; hệ thống giá, Promotions, trade policies, inventory, logistics và seller offers bổ sung ngữ cảnh thương mại; dữ liệu Customers và B2B có thể mở rộng sang Master Data; Orders giữ các quan hệ lịch sử với Checkout, Payments, OMS và quy trình hoàn tất đơn hàng; storefront, nội dung và hệ thống bên ngoài tiếp tục có quyền sở hữu riêng.
Do đó, mô hình chuyển đổi cần giữ keys và relationships thay vì làm phẳng mọi giá trị vào Products, Customers hoặc Orders. Quyền sở hữu rõ ràng giữa các miền VTEX giúp Products tiếp tục được tìm thấy, SKU tiếp tục bán được, Orders tiếp tục có thể hiểu, seller offer tiếp tục xác định đúng bên chịu trách nhiệm, và các tích hợp bên ngoài tiếp tục tham chiếu đúng bản ghi.
Câu hỏi thường gặp
Vì sao SKUs quan trọng khi chuyển đổi sang VTEX?
SKUs thường quyết định các phiên bản có thể bán, giá, inventory, khả năng bán, logistics và lựa chọn trên storefront. Nếu options của Products ở nguồn không được diễn giải thành cấu trúc SKU và specification có thể sử dụng, Products có thể đã được di chuyển nhưng vẫn không đáp ứng yêu cầu thương mại hoặc vận hành.
Mọi attributes ở nguồn có trở thành specifications trong VTEX không?
Không phải mọi attributes đều thuộc specifications. Cần đánh giá theo mục đích: một số thuộc specifications, một số định nghĩa SKUs, một số thuộc nội dung hoặc các tích hợp, và một số nên được loại khỏi phạm vi vì không còn phục vụ mô hình vận hành đích.
Promotions và quy tắc giá ở nguồn có thể di chuyển như trường Products không?
Thông thường không. Promotions, coupons, price tables, điều kiện theo sales channel và cách định giá do hệ thống bên ngoài quyết định cần được rà soát tách khỏi giá cơ sở của Products. Một số giá trị có thể được giữ làm tham chiếu, còn cách hoạt động thương mại hiện tại có thể cần cấu hình VTEX hoặc công việc tích hợp.
Lịch sử đơn hàng có tương đương với cấu hình VTEX OMS không?
Lịch sử đơn hàng giữ ngữ cảnh giao dịch trước đây trong phạm vi được hỗ trợ. Việc xử lý Orders mới thuộc cấu hình hiện tại của Checkout, Payments, OMS, Logistics, inventory và sellers; hai lớp này không thể thay thế cho nhau.
Khi nào dữ liệu VTEX cần mô hình đối tượng riêng?
Cần mô hình đối tượng riêng khi bản ghi ở nguồn không thể trở thành Catalog, Customers, Master Data, Orders, CMS, seller hoặc bản ghi của hệ thống bên ngoài mà không làm mất danh tính hoặc quan hệ. Trước khi mapping từng trường, cần xác định chủ thể sở hữu, key và các liên kết của đối tượng đó.
Trade policies và quan hệ SKU ảnh hưởng đến chuyển đổi VTEX như thế nào?
Products cung cấp ý nghĩa mô tả dùng chung, SKUs đại diện cho các biến thể có thể bán, còn trade policies có thể làm thay đổi nhóm Products được phép bán, giá, logistics hoặc ngữ cảnh thương mại. Mapping phải duy trì các quan hệ đó để không đánh giá một bản ghi là hoàn tất chỉ vì phần vỏ Products đã tồn tại.