Next-Cart

Xác thực sau khi chuyển đổi sang VTEX cần chứng minh rằng các bản ghi đã di chuyển hoạt động đúng trong những miền nền tảng thực sự chi phối hoạt động thương mại. Products có thể tồn tại nhưng SKUs, specifications, quan hệ với trade policy, giá, inventory, logistics, seller offer hoặc chỉ mục storefront lại khiến khách hàng không thể mua. Bản ghi Customers hoặc tài liệu Master Data có thể tồn tại nhưng quan hệ, key hay quy trình sử dụng chúng lại sai. Orders có thể đọc được nhưng seller, chi tiết mặt hàng, thanh toán hoặc bối cảnh hoàn tất đơn hàng không thể đối chiếu.

Vì vậy, kết quả xác thực phải đi theo các quan hệ thực tế trong VTEX: Categories và Brands liên kết với Products; Products liên kết với SKUs và specifications; SKUs liên kết với giá và trạng thái có thể bán; trade policy liên kết Catalog với điều kiện thương mại; seller liên kết offer với Orders marketplace; Customers liên kết với Master Data hoặc bản ghi B2B; còn Orders phải có thể đối chiếu với OMS và dữ liệu logistics.

Dùng Pass, Watch và Block theo từng miền VTEX

  • Pass: kết quả kiểm thử đại diện và các trường hợp ngoại lệ chứng minh chức năng VTEX cần đạt hoạt động đúng.
  • Watch: kết quả có thể sử dụng, nhưng vẫn còn một hạng mục chỉnh sửa không chặn vận hành, công việc cấu hình trên đích, quyết định của chủ thể chịu trách nhiệm hoặc khác biệt đã được rà soát và chấp nhận.
  • Block: vấn đề ảnh hưởng đáng kể đến bán hàng, giá, quyền sở hữu seller, inventory, logistics, Customers, lịch sử đơn hàng, nội dung, SEO, khả năng duy trì tích hợp, yêu cầu tuân thủ hoặc phạm vi di chuyển dữ liệu đã thống nhất.
Miền cần kiểm chứng Kết quả cần chứng minh trên VTEX Trường hợp Block điển hình
Catalog Categories, Brands, Products, SKUs, specifications, hình ảnh và điều kiện kích hoạt hỗ trợ quá trình mua hàng. Một SKU ưu tiên không thể được chọn hoặc mua đúng.
Ngữ cảnh thương mại Trade policies, giá, Promotions và phạm vi Products theo kênh tạo ra kết quả mong muốn. Một kênh quan trọng nhận sai Products hoặc sai giá.
Marketplace Danh tính seller, offers, liên kết Catalog và quyền sở hữu Orders vẫn nhất quán. Products hoặc Orders của seller bị gán sai chủ thể.
Logistics Inventory, warehouses, docks, shipping policies và bối cảnh giao hàng hỗ trợ đúng trạng thái có thể bán. Hàng có tồn kho lại không bán được hoặc hàng không có sẵn vẫn được bán.
Customers và Orders Profiles, bản ghi B2B, Master Data, chi tiết mặt hàng, tổng tiền, trạng thái và tham chiếu vẫn có thể hiểu và đối chiếu. Một đơn hàng trước đây có vai trò quan trọng hoặc quan hệ tài khoản không thể đối chiếu.
Phạm vi tùy chỉnh Apps, các tích hợp, đầu ra di chuyển dữ liệu đã thống nhất, hạng mục di chuyển dữ liệu không theo chuẩn và external IDs hoạt động qua đúng hệ thống sở hữu. Một quy trình quan trọng trước khi vận hành mất dữ liệu hoặc mất key ổn định.

Báo cáo cuối cùng cần nêu rõ account, trade policy, seller, SKU, warehouse, shipping policy, đối tượng Master Data và ngữ cảnh tích hợp đã được rà soát. Một kết luận Pass chung cho Catalog không được che khuất một seller hoặc sales channel đang Block.

Quyết định với VTEX cần giữ rõ quyền sở hữu theo từng miền. Catalog, giá, Promotions, Logistics, OMS, Marketplace, Master Data, Search và đội storefront có thể đưa ra trạng thái khác nhau cho cùng Products hoặc Orders, vì vậy báo cáo trước vận hành không nên ép tất cả thành một trạng thái duy nhất.

Dùng mẫu đại diện để kiểm chứng giả định về Catalog và kênh bán

Bộ mẫu đại diện cần gồm những bản ghi có khả năng bộc lộ kiến trúc VTEX:

  • Products có nhiều SKUs và specifications quyết định biến thể;
  • Categories có nhóm specification cho Products và SKUs được kế thừa;
  • SKUs có hình ảnh, identifiers, giá, inventory và điều kiện kích hoạt;
  • Products xuất hiện dưới các trade policies khác nhau;
  • Products marketplace, sellers, offers và các liên kết Catalog;
  • Customers, bản ghi B2B và tài liệu Master Data có keys ổn định;
  • Orders từ cả kênh bán trực tiếp và marketplace;
  • warehouses, docks, shipping policies và các trường hợp giao hàng ngoại lệ;
  • nội dung storefront ưu tiên, URLs và Products nhạy với tìm kiếm;
  • bản ghi do app sở hữu và external identifiers.

Kết quả kiểm thử trên mẫu đại diện cần cho thấy biến thể ở nguồn đã trở thành SKUs đúng hay chưa, specifications ở cấp Products và SKUs có giữ đúng ý nghĩa hay không, và quan hệ trade policy cùng seller có trỏ tới đúng bản ghi hay không. Một lỗi cấu trúc lặp lại phải được xem là Block trước khi mở rộng di chuyển dữ liệu.

Bộ mẫu cũng cần có bản ghi inactive, hết hàng, chưa hoàn chỉnh hoặc thuộc trường hợp ngoại lệ. Chỉ kiểm tra SKUs đang hoạt động và có dữ liệu sạch không đủ để chứng minh các điều kiện kích hoạt và trạng thái có thể bán vốn thường gây sự cố khi đưa VTEX vào vận hành.

Xác thực Categories, Brands, Products, SKUs và specifications

VTEX Catalog dùng Categories và Brands để tổ chức Products, còn SKUs đại diện cho các biến thể vật lý hoặc lựa chọn thực tế mà khách hàng mua. Các nhóm specification liên kết với Categories xác định trường cho Products và SKUs.

Hạng mục Catalog Pass Watch Block
Quan hệ Products–SKUs Mọi SKU dự kiến đều gắn với đúng Products. Chỉ còn điều chỉnh nhỏ về thứ tự hiển thị. SKUs bị thiếu, trùng hoặc gắn sai Products.
Specifications Giá trị ở Products và SKUs dùng đúng trường, kiểu dữ liệu và tập giá trị. Chỉ còn dọn dẹp dữ liệu ít ảnh hưởng. Ý nghĩa phục vụ chọn biến thể, bộ lọc, tích hợp hoặc tuân thủ bị sai.
Hình ảnh Hình ảnh SKU cần thiết hiển thị và hỗ trợ lựa chọn chính xác. Chỉ còn điều chỉnh thứ tự phụ. SKU ưu tiên không thể kích hoạt hoặc nhận diện đúng.
Brand và Categories Việc gán Products hỗ trợ khả năng tìm thấy và phân loại dự kiến. Còn tinh chỉnh merchandising. Products ưu tiên không thể truy cập hoặc bị phân loại sai.
Identifiers ID của Products, SKU ID, reference, EAN hoặc external keys nhận diện đúng đơn vị. Còn xử lý trùng lặp không quan trọng. Giá, inventory, seller hoặc hệ thống tích hợp trỏ tới sai SKU.
Kích hoạt Products và SKUs đáp ứng các điều kiện để có thể bán như dự kiến. Còn công việc xuất bản có kiểm soát. SKU ưu tiên không thể được cung cấp trên kênh dự kiến.

Cần xác thực qua giao diện quản trị, storefront hoặc kết quả tìm kiếm, trang chi tiết Products, cart, chi tiết mặt hàng trong Orders và các hệ thống bên ngoài. Một bản ghi Catalog không thể Pass chỉ vì ID Products và SKU ID tồn tại.

Khi kiểm tra specifications, phải phân biệt thuộc tính mô tả Products với giá trị dùng để chọn SKU. Một giá trị có thể nhìn đúng trong giao diện quản trị nhưng vẫn sai nếu nằm nhầm trường, nhầm nhóm trường, nhầm đường kế thừa Categories hoặc nhầm cấp SKU.

Nên bao gồm các SKUs mà việc kích hoạt phụ thuộc vào hình ảnh, specifications và dữ liệu thương mại đầy đủ. Cách này giúp phát hiện bản ghi Catalog tồn tại về mặt kỹ thuật nhưng không thể tham gia đúng vào quá trình chọn Products hoặc trạng thái có thể bán trên storefront.

Xác thực trade policies, giá, Promotions và phạm vi Products theo kênh

Trade policies có thể liên kết phạm vi Catalog, giá, Promotions, inventory, logistics, thanh toán và các sales channels khác nhau. Việc xác thực phải diễn ra trong đúng bối cảnh kênh bán.

Hạng mục thương mại Kết quả cần chứng minh
Quan hệ trade policy Products và SKUs dự kiến chỉ có mặt trong đúng bối cảnh kênh.
Giá Đúng SKU, seller, trade policy, số lượng và currency tạo ra đúng giá.
Promotion Điều kiện và ngoại lệ tạo ra kết quả thương mại dự kiến.
Giới hạn phạm vi Products theo kênh Products bị loại khỏi một kênh thực sự không xuất hiện ở kênh đó.
Bối cảnh inventory Trạng thái có thể bán tuân theo quan hệ warehouse và logistics mà trade policy sử dụng.
Bối cảnh thanh toán hoặc checkout Cấu hình hiện tại trên đích hiển thị đúng phương thức, tách biệt với thông tin thanh toán trong Orders trước đây.

Một con số giá đúng trong khu vực quản lý giá chưa đủ để Pass. Cần kiểm tra kết quả phía người mua với đúng seller, trade policy và số lượng. Dùng Block cho lỗi giá hoặc phạm vi Products theo kênh có ảnh hưởng đáng kể; dùng Watch cho phần cấu hình hoặc hiển thị không trọng yếu đã được ghi nhận.

Discount trong Orders trước đây chỉ phản ánh giao dịch đã xảy ra. Chúng không chứng minh Promotions hiện tại hoặc điều kiện trade policy đang được cấu hình đúng.

Khi nhiều trade policies dùng chung một phần Catalog, cần kiểm tra cả SKUs được bao gồm và SKUs phải bị loại. Kết quả dương chứng minh Products có sẵn; kết quả âm chứng minh phạm vi giới hạn và điều kiện thương mại không bị rò sang kênh khác.

Xác thực sellers, offers, liên kết marketplace và quyền sở hữu Orders

Hoạt động marketplace trên VTEX tách danh tính Catalog chuẩn khỏi offers của từng seller. Seller có thể cung cấp giá, inventory, trách nhiệm hoàn tất đơn hàng và quyền sở hữu thương mại cho một mặt hàng được biểu diễn trong Catalog của marketplace.

Cần rà soát:

  • danh tính và trạng thái seller;
  • quan hệ giữa seller SKU hoặc offer với đúng Products và SKUs;
  • bối cảnh trade policy và phạm vi Products theo kênh;
  • giá và inventory của seller;
  • trách nhiệm hoàn tất đơn hàng;
  • key dùng để liên kết Categories hoặc Products marketplace;
  • nguồn Orders, quyền sở hữu seller, commission hoặc tham chiếu settlement khi nằm trong phạm vi;
  • identifiers của marketplace và connector bên ngoài.

Dùng Block khi offer trỏ tới sai SKU, seller mất quyền sở hữu, Orders marketplace bị gán sai seller hoặc thông tin settlement và hoàn tất đơn hàng không xác định được bên chịu trách nhiệm. Dùng Watch cho cấu hình connector còn lại khi quan hệ Catalog đã di chuyển và identifiers đã đầy đủ.

Kết quả marketplace không được gộp trung bình với kết quả cửa hàng trực tiếp. Products có thể Pass ở storefront do doanh nghiệp trực tiếp bán nhưng vẫn Block trên marketplace vì seller offer, trade policy, inventory hoặc liên kết Catalog bị sai.

Xác thực inventory, warehouses, docks, shipping policies và bối cảnh OMS

Logistics trên VTEX có thể liên kết inventory với warehouses, loading docks, shipping policies, carriers, trade policies và lựa chọn giao hàng. Cần kiểm tra những quan hệ thực sự quyết định trạng thái có thể bán và cam kết giao hàng.

Hạng mục logistics Trọng tâm xác thực
Inventory Số lượng thuộc đúng SKU và warehouse.
Warehouse Warehouse có đúng tồn kho và quan hệ dock dự kiến.
Loading dock Dock liên kết đúng warehouses, carriers và trade policies.
Shipping policy Quy tắc, mức phí, mức dịch vụ và trạng thái hoạt động hỗ trợ đúng bối cảnh đích.
Trạng thái có thể bán của SKU Người mua thấy đúng trạng thái có sẵn và lựa chọn giao hàng theo trade policy và seller.
OMS context Orders, quy trình hoàn tất đơn hàng, tracking và trạng thái vận hành có thể đối chiếu với luồng thực tế.
Hệ thống bên ngoài tiếp tục là nguồn dữ liệu chính ERP, WMS hoặc hệ thống carrier nhận diện đúng SKU, warehouse và Orders.

Tổng inventory đúng vẫn có thể thất bại nếu tồn kho nằm ở sai warehouse hoặc warehouse không kết nối với dock và shipping policy liên quan. Các lỗi làm SKU ưu tiên không thể bán phải được đánh dấu Block.

Orders được di chuyển không cấu hình logistics đang hoạt động. Warehouses, docks, shipping policies, carriers, pickup points, cách áp dụng SLA và hoạt động OMS hiện tại cần được phê duyệt riêng trên đích.

Cần kiểm tra ít nhất một tổ hợp địa điểm giao hàng và SKU cho mỗi tuyến logistics quan trọng. Cách này bộc lộ quan hệ warehouse–dock–shipping policy bị hỏng mà tổng inventory hoặc trạng thái trong giao diện quản trị không thể hiện được.

Xác thực Customers, quan hệ B2B, Master Data và lịch sử đơn hàng

Dữ liệu liên quan đến Customers có thể trải rộng trên danh tính profile, địa chỉ, tổ chức B2B, roles, cost centers, consent, CRM IDs và tài liệu Master Data. Cần xác thực đúng đối tượng và key, không chỉ các trường hiển thị.

Hạng mục Customers Kết quả cần chứng minh
Danh tính profile Email, document, phone hoặc external key nhận diện đúng người.
Địa chỉ Địa chỉ hiện tại trong profile và địa chỉ lưu trong Orders trước đây được phân biệt khi cần.
Đối tượng B2B Organization, user, role, cost center, Catalog hoặc quan hệ phê duyệt vẫn gắn đúng.
Tài liệu Master Data Đối tượng, document ID, schema, trường, quan hệ và hệ thống sử dụng đều đúng.
External identifier CRM, ERP, loyalty, marketplace hoặc hệ thống hỗ trợ có thể tìm đúng Customers hoặc organization.
Lịch sử đơn hàng Customers, seller, chi tiết SKU, giá, Promotions, thanh toán, shipping, trạng thái và external IDs vẫn có thể hiểu và đối chiếu.

Dùng Block khi việc hợp nhất danh tính không an toàn, quan hệ B2B bị hỏng, tham chiếu Master Data trỏ sai đối tượng hoặc Orders quan trọng không thể đối chiếu.

Orders trước đây không chứng minh Checkout, Payments, Promotions, Logistics, OMS, notifications, invoices, refunds hoặc quy trình phân nhóm Customers hiện tại hoạt động đúng. Các hạng mục này cần được phê duyệt vận hành riêng.

Khi kiểm tra Master Data, cần bao gồm trường quan hệ và tài liệu được tham chiếu chứ không chỉ nội dung document. Một giá trị profile có thể đúng nhưng vẫn thất bại nếu organization, cost center, app hoặc workflow trỏ tới identifier cũ.

Xác thực storefront, tìm kiếm, URLs và khả năng duy trì nội dung

Kết quả storefront trên VTEX có thể liên quan đến chỉ mục tìm kiếm, khả năng bán Products, Categories, Brands, filters, trang nội dung, điều hướng, routes SEO và phần hiển thị do app quản lý. Cần kiểm tra từ hành trình người mua thay vì chỉ nhìn sự tồn tại của Catalog.

Bộ kiểm thử đại diện nên gồm:

  • tìm kiếm Products và SKUs ưu tiên;
  • khả năng tìm thấy Categories và Brands;
  • bộ lọc dùng specifications;
  • lựa chọn và trạng thái có thể bán trên trang chi tiết Products;
  • URLs nguồn ưu tiên và trang đích dự kiến;
  • metadata, media và internal links;
  • nội dung chính sách, dịch vụ và chiến dịch;
  • khác biệt locale hoặc domain khi có;
  • tham chiếu nội dung do storefront Headless hoặc app quản lý.

Dùng Block khi các trang ưu tiên không được lập chỉ mục trên diện rộng, việc chọn SKU bị hỏng, nội dung bắt buộc bị thiếu hoặc một URL có giá trị cao bị mất hoặc không còn đúng đích. Dùng Watch cho công việc trình bày, lập chỉ mục hoặc metadata có kiểm soát khi bản ghi nền tảng và chủ thể chịu trách nhiệm đã đầy đủ.

Catalog, Search và phần triển khai storefront có liên quan nhưng không đồng nhất. Products có thể tồn tại trong Catalog nhưng không xuất hiện trong Search hoặc không có sẵn trong trade policy dự kiến.

Xác thực apps, các tích hợp, điều chỉnh được hỗ trợ và đầu ra tùy chỉnh

Cửa hàng VTEX thường kết nối Catalog, hệ thống giá, Logistics, OMS, Master Data, sellers, Search, storefront apps, ERP/PIM/WMS, CRM, marketplaces, Tax, thanh toán và hệ thống analytics. Dữ liệu tùy chỉnh phải được xác thực theo đúng miền và hệ thống thực sự sử dụng dữ liệu đó.

Với mỗi giá trị quan trọng, cần ghi:

  • miền VTEX và đối tượng sở hữu;
  • app hoặc hệ thống bên ngoài;
  • identifier của Products, SKU, seller, Customers, Master Data hoặc Orders;
  • hướng đồng bộ dự kiến;
  • kết quả kiểm thử đại diện cho trường hợp thành công và ngoại lệ;
  • bên chịu trách nhiệm cho phần triển khai hoặc cấu hình còn lại.

Các đầu ra được hỗ trợ và đầu ra tùy chỉnh đã thống nhất phải được xác thực theo phạm vi đã ghi nhận. Một specification đã chuyển đổi, liên kết seller, tài liệu Master Data, external ID hoặc quan hệ tùy chỉnh cần được kiểm thử qua API, app, module quản trị, storefront hoặc hệ thống bên ngoài đang sử dụng giá trị đó.

Dùng Block khi giá trị không còn chủ thể sở hữu, không tương thích hoặc không thể truy vết trong một workflow quan trọng trước khi vận hành. Dùng Watch khi phần triển khai app hoặc tích hợp còn lại nằm ngoài phạm vi di chuyển dữ liệu nhưng miền VTEX, cấu trúc dữ liệu trao đổi, key ổn định và bên chịu trách nhiệm đã đầy đủ.

Phân biệt kiểm thử trên mẫu đại diện và bằng chứng từ phạm vi di chuyển dữ liệu rộng hơn

Kiểm thử trên mẫu đại diện chứng minh những giả định cấu trúc đã chọn. Di chuyển Khi được thực hiện trên phạm vi rộng hơn, kết quả phải chứng minh tính đầy đủ của Catalog, kênh, seller, logistics, Customers, Orders, nội dung và các tích hợp.

Kết quả từ phạm vi di chuyển dữ liệu rộng hơn cần bao gồm:

  • mọi mô hình Products và SKUs chính;
  • đầy đủ trường và giá trị specifications;
  • phạm vi Products và giá theo trade policy;
  • toàn bộ seller offers và liên kết marketplace trong phạm vi;
  • inventory, warehouses, docks và tham chiếu logistics liên quan;
  • Customers, bản ghi B2B, tài liệu Master Data và lịch sử đơn hàng;
  • storefront, Search, URLs ưu tiên và nội dung;
  • mọi đầu ra được hỗ trợ và tùy chỉnh đã thống nhất;
  • ngoại lệ liên quan đến app và external IDs;
  • thay đổi phát sinh sau đợt kiểm thử mẫu đại diện.

Phải mở lại một kết luận Pass từ kiểm thử đại diện khi phạm vi rộng hơn phát hiện specifications của SKU không nhất quán, thiếu hình ảnh, thiếu điều kiện kích hoạt, gán sai trade policy, lỗi liên kết seller, warehouse không khớp, tài liệu Master Data mất tham chiếu, Customers trùng hoặc Orders không thể đối chiếu.

Cần phân nhóm ngoại lệ theo trade policy, seller, Categories, dòng sản phẩm, nhóm specification, warehouse, đối tượng Customers/B2B và giai đoạn dữ liệu nguồn. Tổng số liệu có thể che khuất một lỗi hoàn toàn ở riêng một kênh hoặc seller.

Xác thực lại sau các lần di chuyển dữ liệu tiếp theo

Hành động tiếp theo Phạm vi cần xác thực lại trên VTEX
tiếp tục với cấu hình đã được chấp nhận Xác thực bản ghi mới đủ điều kiện và xác nhận các giả định trước đó về Catalog, trade policy, seller, logistics, Customers, Orders, nội dung và các tích hợp vẫn đúng.
tiếp tục với cấu hình đã điều chỉnh Xác thực lại mọi quan hệ chịu ảnh hưởng của bộ lọc, quan hệ trường, lựa chọn loại dữ liệu hoặc cấu hình đã thay đổi, kể cả các phần từng được phê duyệt.
tạo một kết quả di chuyển dữ liệu mới riêng biệt Xem đầu ra là một kết quả chuyển đổi riêng biệt và lặp lại đầy đủ việc xác thực VTEX cũng như quyết định đưa cửa hàng vào vận hành.

Cần giữ đồng thời các quyết định trước và sau. Nếu danh tính Products hoặc SKUs, gán trade policy, liên kết seller hoặc cách khớp Customers thay đổi, Orders, tham chiếu logistics và các tích hợp đã được phê duyệt trước đó cũng có thể phải rà soát lại.

Việc xác thực lại VTEX phải đi theo hướng tham chiếu giữa các miền. Một thay đổi trong cách gắn SKU có thể ảnh hưởng đến giá, inventory, seller offers, logistics, Search và kết quả kiểm tra Orders; một thay đổi key của Customers có thể ảnh hưởng Master Data, B2B và quan hệ với lịch sử đơn hàng.

Xây dựng quyết định đưa VTEX vào vận hành

Chỉ phê duyệt đưa cửa hàng vào vận hành khi:

  • không còn Block chưa xử lý ảnh hưởng Catalog, giá, sellers, inventory, logistics, Customers, lịch sử đơn hàng, khả năng tìm thấy trên storefront, SEO, yêu cầu tuân thủ hoặc các tích hợp;
  • kiểm thử đại diện và bằng chứng từ phạm vi di chuyển dữ liệu rộng hơn đã hoàn tất;
  • các đầu ra được hỗ trợ và tùy chỉnh đã thống nhất được chứng minh;
  • giá, Promotions, Checkout, Payments, Logistics, OMS, hoạt động seller, Search và việc triển khai app đang hoạt động trên VTEX đã được phê duyệt riêng;
  • các lần di chuyển dữ liệu tiếp theo áp dụng đã được xác thực lại;
  • mỗi mục Watch có người chịu trách nhiệm và ngày hoàn tất.

Cần giữ trạng thái riêng cho mức độ sẵn sàng của Catalog, kênh/giá, marketplace, logistics, dữ liệu lịch sử, storefront/Search và các tích hợp. Một storefront trực tiếp Pass không được che khuất quan hệ seller hoặc logistics đang Block.

Kết luận

Xác thực VTEX cần chứng minh Catalog, SKUs, specifications, trade policies, sellers, logistics, Customers, Master Data, Orders, nội dung và các tích hợp phối hợp đúng trong bối cảnh sales channel dự kiến.

Kiểm thử trên mẫu đại diện xác nhận giả định cấu trúc, di chuyển dữ liệu trên phạm vi rộng hơn chứng minh tính đầy đủ và các trường hợp ngoại lệ, còn những lần di chuyển dữ liệu tiếp theo cần mức xác thực lại tương ứng. Quyết định đưa cửa hàng vào vận hành phải dựa trên kết quả Pass, Watch và Block đã được ghi nhận rõ.

Câu hỏi thường gặp

Vì sao cần xác thực Products và SKUs trên VTEX riêng biệt?

Products lưu danh tính Catalog chung, còn SKUs đại diện cho đơn vị vật lý hoặc lựa chọn thực tế mà khách hàng mua. Specifications, hình ảnh, giá, inventory và seller offers có thể phụ thuộc vào SKU.

Kết quả liên quan đến trade policy nên được kiểm tra như thế nào?

Cần kiểm tra đồng thời đúng sales channel, seller, SKU, số lượng, currency, giá, Promotion, inventory, logistics và bối cảnh thanh toán thay vì chỉ xem một bản ghi trong giao diện quản trị.

Một kết quả Pass ở cửa hàng trực tiếp có đủ để phê duyệt marketplace không?

Marketplace vẫn cần bằng chứng riêng cho danh tính seller, offers, liên kết Catalog, trade policies, inventory, trách nhiệm hoàn tất đơn hàng và quyền sở hữu Orders marketplace. Kết quả Pass ở cửa hàng trực tiếp không thay thế được phần kiểm tra này.

Orders đã di chuyển có chứng minh Logistics và OMS đang hoạt động trên VTEX đã sẵn sàng không?

Lịch sử đơn hàng chỉ chứng minh giao dịch trước đây vẫn có thể đọc và đối chiếu. Warehouses, docks, shipping policies, carriers, Payments, OMS và quy trình hoàn tất đơn hàng hiện tại phải được phê duyệt riêng trên đích.

Tài liệu Master Data nên được phê duyệt như thế nào?

Xác nhận đối tượng, document ID, schema, giá trị trường, quan hệ, external keys và app hoặc workflow thực sự sử dụng tài liệu.

Sau một lần di chuyển dữ liệu tiếp theo của VTEX, những gì phải được xác thực lại?

Phải xác thực lại mọi bản ghi VTEX mới hoặc đã thay đổi và mọi giả định về trade policy, seller, offer, logistics, Master Data, storefront hoặc tích hợp bị tác động bởi lần di chuyển dữ liệu đó. Nếu tạo một kết quả di chuyển dữ liệu mới riêng biệt, cần thiết lập lại toàn bộ cơ sở kiểm chứng cho kết quả đó.