Sau khi dữ liệu được chuyển sang EasyStore by JoomShaper trong vai trò Nền tảng đích, xác thực phải chứng minh cửa hàng có thể hoạt động như một môi trường thương mại điện tử trên Joomla, chứ không chỉ cho thấy các bản ghi đã xuất hiện trong giao diện quản trị. Products, variants, Categories, Customers, Orders, Coupons, tồn kho, refunds, thuế, vận chuyển, thông tin thanh toán, các đường dẫn checkout, Joomla menus và phần trình bày storefront đều ảnh hưởng đến việc kết quả có thực sự sử dụng được sau khi chính thức vận hành hay không.
Quy trình xác thực có giá trị nhất sẽ kết nối dữ liệu đã di chuyển với hành trình mua hàng và nhu cầu vận hành của doanh nghiệp. Products phải có thể bán được. Variants phải thể hiện rõ lựa chọn. Categories phải giúp Customers tìm đúng mặt hàng. Dữ liệu Customers cần tiếp tục hỗ trợ chăm sóc khách hàng và tra cứu Orders. Lịch sử đơn hàng phải giữ đủ ý nghĩa thương mại để bộ phận hỗ trợ, tài chính, xử lý đơn hàng và hoàn tiền có thể sử dụng. Website Joomla cũng phải dẫn Customers đến đúng Products, tài khoản, cart và checkout.
Xác thực phải chứng minh EasyStore thực sự sử dụng được
Xác thực EasyStore cần trả lời một câu hỏi thực tế: kết quả chuyển đổi có giữ được những ý nghĩa doanh nghiệp cần để vận hành trong EasyStore by JoomShaper hay không? Câu trả lời phụ thuộc vào ba nhóm yếu tố có liên hệ với nhau.
| Nhóm cần xác thực | Phạm vi | Điều cần chứng minh |
|---|---|---|
| Dữ liệu thương mại | Products, variants, Categories, tags, Customers, Orders, Coupons, Reviews, tồn kho, refunds, thuế, vận chuyển và thông tin thanh toán | Bản ghi tồn tại, đọc được và vẫn mang đúng ý nghĩa thương mại. |
| Storefront Joomla | Menus, aliases, đường dẫn Categories, Products, tài khoản và checkout, templates, Modules cùng liên kết nội dung | Customers có thể đi đến những hành trình mua hàng quan trọng mà không gặp điều hướng lỗi hoặc gây nhầm lẫn. |
| Hành vi vận hành | Thuế, vận chuyển, checkout, kết nối thanh toán, tồn kho, refunds, Coupons, thông báo, analytics và dữ liệu riêng | Đội ngũ phân biệt được dữ liệu lịch sử đã di chuyển, cấu hình trên đích và những yêu cầu cần xử lý riêng. |
Không nên xác thực ba nhóm này như những ô kiểm tra tách rời. Products có thể đúng nhưng Customers vẫn khó truy cập storefront. Hồ sơ Customers có thể đã được di chuyển trong khi quan hệ với Orders khó sử dụng. Giá trị thuế có thể xuất hiện đúng trên lịch sử đơn hàng nhưng quy tắc thuế cho giao dịch mới vẫn cần được cấu hình trên đích. Mỗi vấn đề cần được phân loại rõ là kết quả di chuyển dữ liệu, công việc cấu hình EasyStore/Joomla, điều chỉnh đã thống nhất trong phạm vi được hỗ trợ, yêu cầu xử lý riêng, công việc xây dựng lại thủ công hay giới hạn đã được chấp nhận.
Xác thực Products, variants và ý nghĩa catalog
Xác thực Products phải chứng minh catalog vẫn dễ hiểu về mặt thương mại trong EasyStore. Việc rà soát cần bao gồm cả giao diện quản trị EasyStore lẫn trải nghiệm Products mà Customers nhìn thấy trên storefront.
Bộ mẫu cần có Products thông thường và những Products phản ánh đúng cấu trúc bán hàng thực tế: Products có nhiều variants, nhiều hình ảnh, đang giảm giá, nhạy với tồn kho, ảnh hưởng đến vận chuyển và các bản ghi từng phụ thuộc vào trường hoặc extensions riêng ở nguồn. Variants cần được chú ý đặc biệt vì lỗi ở cấp variant có thể không xuất hiện trong danh sách Products. Một bản ghi Products có thể trông đầy đủ trong giao diện quản trị nhưng Customers lại gặp lựa chọn khó hiểu, thiếu hình ảnh, chênh lệch giá sai hoặc trạng thái tồn kho gây nhầm lẫn.
| Products đại diện | Trọng tâm xác thực | Dấu hiệu không đạt |
|---|---|---|
| Products đơn giản | Tên, SKU, mô tả, giá, hình ảnh, Categories và khả năng hiển thị | Products xuất hiện nhưng thiếu thông tin Customers cần để ra quyết định mua. |
| Products có nhiều variants | Tên option, giá trị option, chênh lệch giá, tồn kho, hình ảnh và ý nghĩa của mặt hàng được ghi trong Orders | Customers không thể chọn rõ ràng kích thước, màu sắc, chất liệu hoặc lựa chọn Products khác. |
| Products giảm giá | Giá khuyến mãi, bối cảnh Coupons, lịch sử promotion và cách hiển thị giá | Kỳ vọng về giá đang áp dụng bị nhầm với dữ liệu giảm giá lịch sử. |
| Products ảnh hưởng đến vận chuyển | Trọng lượng, kích thước, nhóm vận chuyển, kỳ vọng giao hàng và quy tắc theo địa điểm khi có | Dữ liệu Products không đủ để hỗ trợ cấu hình vận chuyển dự kiến. |
| Products có trường riêng | Trường đặc thù ở nguồn, giá trị do extension quản lý, tham chiếu ERP hoặc trường merchandising riêng | Cần rà soát điều chỉnh đã thống nhất, phương án xử lý riêng hoặc công việc thủ công. |
Quy trình xác thực Products tốt cần kiểm tra liệu Products có thể được tìm thấy, hiểu đúng, lựa chọn, thêm vào cart và diễn giải đúng trong lịch sử đơn hàng hay không. Chỉ xác nhận số lượng bản ghi và tên Products là chưa đủ.
Xác thực Categories, tags và cách Customers tìm Products trên storefront
EasyStore hỗ trợ tổ chức Products thông qua các bản ghi như Categories, tags và các nhóm Products, nhưng khả năng Customers tìm thấy Products còn phụ thuộc vào cấu trúc website Joomla. Menus, aliases, internal links, landing pages, Modules, templates và các khu vực SP Page Builder đều có thể quyết định Products sau di chuyển dữ liệu có dễ truy cập và đủ thuyết phục hay không.
Phạm vi xác thực nên bao gồm Categories cấp cao, Categories sâu hơn khi cấu trúc phân cấp có ý nghĩa, Categories tạo doanh thu lớn, Categories có ít Products nhưng mang giá trị chiến lược và Categories liên kết với landing pages hoặc chiến dịch. Nếu cửa hàng dùng tags, thương hiệu, collections hoặc nhóm tương tự, cần xác nhận những nhóm này vẫn phục vụ đúng mục đích sau khi chuyển đổi.
| Khu vực khám phá Products | Nội dung cần xác thực | Vì sao quan trọng |
|---|---|---|
| EasyStore Categories | Tên, cấu trúc phân cấp, Products được gán, trạng thái hiển thị và cách trang Categories hoạt động trên storefront | Categories phải tiếp tục hỗ trợ duyệt và tìm Products. |
| Tags hoặc nhóm Products | Cách nhóm Products, ý nghĩa khi lọc và mục đích merchandising | Dữ liệu nhóm không nên chỉ còn là nhãn nhưng không giúp Customers tìm Products. |
| Joomla menus | Điểm truy cập cửa hàng, liên kết Categories, Products, tài khoản và checkout | Products có thể tồn tại nhưng Customers vẫn khó tìm đến. |
| Internal links | Liên kết từ các trang nội dung, landing pages, trang chiến dịch và Blog Posts | Những đường dẫn tạo traffic quan trọng có thể trỏ đến URL cũ hoặc trang không còn tồn tại. |
| Khu vực SP Page Builder | Khối Products, bố cục khuyến mãi, cách hiển thị Products riêng và landing pages | Phần trình bày có thể cần được triển khai riêng ngoài di chuyển dữ liệu. |
Mục tiêu xác thực không phải tự động tái tạo mọi đường dẫn cũ. Dự án cần chứng minh từng đường dẫn ưu tiên đã có kết quả được chấp nhận: được giữ lại sau di chuyển dữ liệu, chuyển hướng, xây dựng lại, cấu hình lại hoặc chủ động loại bỏ.
Xác thực Customers, tài khoản và lịch sử mua hàng
Xác thực Customers phải chứng minh bản ghi Customers vẫn hữu ích trong môi trường EasyStore và Joomla. Tên và email chưa đủ. Cần kiểm tra danh tính, địa chỉ, bối cảnh tài khoản và quan hệ với Orders có đủ rõ để phục vụ vận hành sau khi cửa hàng đi vào hoạt động hay không.
Bộ mẫu tốt nên có một người mua gần đây, Customers mua lặp lại, Customers có lịch sử mua hàng quan trọng, Customers có nhiều địa chỉ, khách mua không đăng ký nếu có, một trường hợp liên hệ trùng lặp và Customers liên quan đến Orders đã refund, giảm giá hoặc có nhiều variants. Nếu Cửa hàng nguồn dùng chương trình thành viên, nhóm Customers, trường wholesale, quy trình phê duyệt, loyalty, mã định danh bên ngoài, CRM hoặc quan hệ Joomla user, các trường hợp đó cần được rà soát riêng.
| Hạng mục xác thực Customers | Điều cần chứng minh | Vấn đề thường gặp |
|---|---|---|
| Thông tin liên hệ | Tên, email, số điện thoại, địa chỉ thanh toán và giao hàng đọc được và đúng | Bản ghi tồn tại nhưng không hỗ trợ chăm sóc Customers. |
| Bối cảnh tài khoản | Kỳ vọng về Joomla user/tài khoản được hiểu và kiểm thử khi có liên quan | Customers thương mại bị nhầm với toàn bộ hành vi tài khoản Joomla. |
| Quan hệ Customers và Orders | Hồ sơ Customers quan trọng kết nối được với lịch sử đơn hàng hữu ích | Đội ngũ hỗ trợ không thể truy vết giao dịch từ hồ sơ Customers. |
| Bản ghi trùng hoặc khách mua không đăng ký | Trường hợp guest, email trùng và hồ sơ thiếu thông tin đều được hiểu rõ | Danh tính trở nên khó phân biệt sau di chuyển dữ liệu. |
| Dữ liệu Customers riêng | Chương trình thành viên, CRM, loyalty, mã số thuế, company hoặc mã định danh bên ngoài được phân loại | Nhu cầu xử lý riêng chỉ được phát hiện quá muộn. |
Xác thực Customers cần tập trung vào khả năng sử dụng. Một bản ghi Customers sau di chuyển dữ liệu có giá trị hạn chế nếu đội ngũ hỗ trợ không thể tìm lịch sử mua hàng hoặc hiểu bối cảnh thương mại đằng sau các Orders trước đó.
Xác thực Orders, refunds và bối cảnh thương mại
Xác thực Orders phải chứng minh các bản ghi giao dịch lịch sử vẫn đọc được và có ích. Orders có thể gồm chi tiết mặt hàng, variants, giảm giá, Coupons, thuế, phí vận chuyển, tham chiếu thanh toán, bối cảnh refund, trạng thái, địa chỉ và quan hệ Customers. Quy trình xác thực cần giữ đúng ý nghĩa lịch sử mà không nhầm dữ liệu này với cấu hình EasyStore đang dùng cho giao dịch mới.
Bộ các bản ghi Orders đại diện nên có cả giao dịch thanh toán thông thường và các trường hợp biên: Orders giảm giá, đã refund, có variants, nhạy với vận chuyển, nhạy với thuế, giá trị cao, đã hủy và Orders liên kết với hồ sơ Customers quan trọng. Nếu Orders nguồn dùng mã định danh bên ngoài, tham chiếu ERP/Marketplace, trạng thái riêng hoặc trường do các tích hợp quản lý, các ví dụ đó cần được đánh dấu để rà soát riêng.
| Orders đại diện | Nội dung cần xác nhận | Vì sao quan trọng |
|---|---|---|
| Orders thanh toán thông thường | Số đơn, ngày, Customers, chi tiết mặt hàng, tổng tiền và địa chỉ | Xác lập mức tối thiểu để lịch sử giao dịch có thể đọc và tra cứu. |
| Orders có variants | Giá trị option đã chọn và tên mặt hàng trong Orders | Chứng minh lựa chọn Products vẫn có thể hiểu sau di chuyển dữ liệu. |
| Orders có giảm giá hoặc Coupons | Coupons, mức giảm, giá khuyến mãi và ý nghĩa tổng tiền cuối cùng | Tránh nhầm giảm giá lịch sử với promotion đang hoạt động. |
| Orders đã refund | Bối cảnh refund một phần/toàn bộ và trạng thái có thể hiểu | Hỗ trợ chăm sóc Customers và đối chiếu tài chính. |
| Orders có vận chuyển/thuế | Phương thức vận chuyển, số tiền thuế, khu vực, địa chỉ và tổng tiền | Giúp tách bối cảnh giao dịch đã ghi nhận khỏi cấu hình thuế/vận chuyển ở đích. |
Các tham chiếu thanh toán cần được xem là bối cảnh giao dịch đã ghi nhận. Kết nối thanh toán đang hoạt động, phương thức thanh toán, luồng checkout, quy tắc thuế và phương thức vận chuyển vẫn cần được cấu hình và kiểm thử trong EasyStore/Joomla.
Xác thực riêng những hành vi phụ thuộc cấu hình
Thông tin kiểm chứng phải xác định rõ cấu hình nào chịu trách nhiệm và tình huống nào phụ thuộc vào cấu hình đó. Một giá trị lịch sử có thể hoàn toàn đúng trong khi quy tắc đang hoạt động vẫn chưa tồn tại, vì vậy cần ghi nhận riêng kết quả kiểm tra di chuyển dữ liệu và kết quả kiểm tra phần triển khai trên đích.
Một số hạng mục EasyStore không phải là những bản ghi đơn giản được di chuyển. Cách quản lý tồn kho, áp dụng thuế, xử lý vận chuyển, kết nối thanh toán và cấu hình checkout, Coupons, refunds, tạo tài khoản, email, analytics và thông báo cửa hàng có thể phụ thuộc vào cấu hình ở đích. Xác thực phải phân biệt dữ liệu đã di chuyển với thiết lập doanh nghiệp cần cấu hình trong EasyStore hoặc Joomla.
| Hạng mục phụ thuộc cấu hình | Câu hỏi xác thực | Hướng xử lý có khả năng phù hợp |
|---|---|---|
| Tồn kho | Giá trị tồn kho, tồn kho theo variant và trạng thái có thể bán có hỗ trợ bán hàng đúng không? | Xác thực di chuyển dữ liệu kết hợp rà soát cấu hình trên đích. |
| Thuế | Giá trị thuế lịch sử có đọc được không, và quy tắc thuế đang hoạt động đã được cấu hình riêng chưa? | Cấu hình và kiểm thử trên đích. |
| Vận chuyển | Giá trị vận chuyển lịch sử có đọc được không, và khu vực/phương thức vận chuyển mới đã được thiết lập chưa? | Cấu hình trên đích và kiểm thử checkout. |
| Thanh toán | Tham chiếu thanh toán có ích không, và các tích hợp đang hoạt động đã được cấu hình chưa? | Thiết lập trên đích, không thể chứng minh chỉ từ lịch sử đơn hàng. |
| Coupons và promotions | Giảm giá đã di chuyển hoặc dữ liệu giảm giá lịch sử có dễ hiểu không, và promotions đang hoạt động có đúng chủ đích không? | Xác thực di chuyển dữ liệu kết hợp cấu hình EasyStore. |
| Đường dẫn checkout và tài khoản | Customers có thể đi từ Products đến cart, checkout, tài khoản và xác nhận Orders không? | Thiết lập Joomla/EasyStore và kiểm thử storefront. |
Sự phân biệt này ngăn những kết luận sai. Lỗi checkout có thể thuộc cấu hình ở đích chứ không phải lỗi di chuyển dữ liệu. Giá trị thuế lịch sử có thể đúng dù quy tắc thuế đang hoạt động vẫn chưa được thiết lập. Coupons có thể được giữ trong lịch sử nhưng promotion mới vẫn cần được cấu hình lại.
Xác thực ranh giới với SP Page Builder và phần trình bày
JoomShaper đặt EasyStore trong hệ sinh thái có SP Page Builder, vì vậy cách trình bày cửa hàng có thể phụ thuộc vào bố cục Page Builder, templates, Modules, khối Products, landing pages và nội dung khuyến mãi. Những thành phần này có thể ảnh hưởng trực tiếp đến trải nghiệm Customers ngay cả khi dữ liệu thương mại cốt lõi đã được di chuyển đúng.
Cần xác định phần nào của giao diện là dữ liệu đã di chuyển, phần nào là công việc triển khai Joomla/SP Page Builder và phần nào được chủ động xây dựng lại thủ công. Trang Products, bố cục danh sách Products, khu vực homepage, landing pages cho chiến dịch, khối Products riêng và các điểm dẫn vào checkout cần được kiểm tra khi chúng ảnh hưởng đến doanh thu hoặc khả năng duy trì giá trị SEO.
| Phần phụ thuộc vào trình bày | Điều cần chứng minh | Cách diễn giải đúng |
|---|---|---|
| Bố cục trang Products | Thông tin Products hiển thị rõ và hỗ trợ Customers ra quyết định | Dữ liệu di chuyển dữ liệu và cách trình bày có liên quan nhưng là hai phần riêng. |
| Khối danh sách Products | Products quan trọng xuất hiện ở đúng khu vực dự kiến trên trang | Vị trí trong Page Builder có thể cần được triển khai thủ công. |
| Landing pages | Trang chiến dịch hoặc SEO dẫn đến đúng đường dẫn Products/Categories liên quan | Có thể cần redirects, internal links và xây dựng lại nội dung. |
| Hành vi Template/Module | Các trang cửa hàng hiển thị nhất quán và vẫn sử dụng được | Công việc với Template không tự được giải quyết bằng di chuyển dữ liệu. |
| Trường hiển thị riêng | Thông tin đặc biệt xuất hiện đúng nơi doanh nghiệp cần | Có thể cần xử lý riêng hoặc triển khai thủ công. |
Không nên đánh giá di chuyển dữ liệu chỉ dựa trên mức độ giống giao diện cũ. Câu hỏi quan trọng hơn là dữ liệu đã di chuyển và phần triển khai ở đích khi kết hợp với nhau có tiếp tục hỗ trợ đúng hành trình bán hàng hay không.
Xác thực dữ liệu riêng và phần xử lý đặc biệt
EasyStore có thể hoạt động cùng Joomla extensions khác, trường tùy chỉnh, SP Page Builder addons, các tích hợp ERP/CRM, công cụ analytics, hệ thống xử lý đơn hàng, nguồn dữ liệu Marketplace hoặc quy tắc riêng ở nguồn. Xác thực cần phân loại rõ cách xử lý các trường hợp đặc biệt thay vì xem mọi giá trị nhìn thấy ở nguồn là dữ liệu di chuyển dữ liệu thông thường.
Cần phân biệt những điều chỉnh đã được thống nhất trong phạm vi xử lý được hỗ trợ với công việc xử lý riêng ngoài phạm vi thông thường. Các điều chỉnh có giới hạn rõ có thể bao gồm lọc, chuyển trường hoặc cấu hình trong cách xử lý được hỗ trợ. Xử lý riêng cần được xem xét khi yêu cầu liên quan đến bản ghi không được hỗ trợ, trường cần xử lý theo cách riêng, dữ liệu do extensions sở hữu, mã định danh thuộc hệ thống bên ngoài, chuyển đổi theo quy tắc riêng, Custom Platform hoặc quan hệ không tiêu chuẩn.
| Vấn đề phát hiện khi xác thực | Cách phân loại có khả năng phù hợp |
|---|---|
| Bản ghi được hỗ trợ cần điều chỉnh cách chuyển sang trường đích | Có thể chỉ cần rà soát một điều chỉnh trong phạm vi được hỗ trợ. |
| Bản ghi được hỗ trợ cần lọc hoặc loại trừ | Có thể chỉ cần rà soát một điều chỉnh trong phạm vi được hỗ trợ. |
| Dữ liệu Products/Customers/Orders đến từ một Joomla extension riêng | Cần rà soát phương án xử lý riêng. |
| Mã định danh bên ngoài phải tiếp tục liên kết với ERP, CRM, hệ thống xử lý đơn hàng hoặc báo cáo | Cần rà soát phương án xử lý riêng. |
| Bố cục Page Builder phải tái tạo cách trình bày ở nguồn | Cần công việc triển khai hoặc rà soát phương án xử lý riêng tùy phạm vi. |
| Thanh toán/vận chuyển/thuế đang hoạt động chưa được cấu hình | Thuộc thiết lập trên đích, không phải dữ liệu đã di chuyển. |
Kết quả xác thực phải đưa từng vấn đề vào một nhóm xử lý rõ ràng. Không nên để các phát hiện chưa được phân loại nằm lẫn trong một danh sách “cleanup” chung.
Xây dựng báo cáo xác thực EasyStore có thể lặp lại
Xác thực EasyStore cần kết thúc bằng một quyết định có thể kiểm chứng lại, không phải một tập screenshots. Mỗi phát hiện cần ghi rõ Products, variant, Customers, Orders, Categories, collection, Joomla route, khối SP Page Builder hoặc bản ghi riêng đã được kiểm tra, cùng với kết quả kỳ vọng, kết quả quan sát được, người phụ trách và hành động tiếp theo.
| Trạng thái quyết định | Thông tin EasyStore cần có | Ý nghĩa đối với việc vận hành |
|---|---|---|
| Pass | Cách Products và variants hoạt động, khả năng tìm Products, lịch sử Customers và Orders, routes ưu tiên và các đầu ra đã thống nhất đều đúng và có thể kiểm tra lặp lại. | Hạng mục đã rà soát có thể được phê duyệt để chính thức vận hành. |
| Watch | Kết quả vẫn sử dụng được nhưng còn công việc về template, SP Page Builder, điều hướng, nội dung, cấu hình trên đích hoặc cleanup không chặn vận hành và đã được ghi nhận. | Chỉ tiếp tục nếu đã có người phụ trách và điều kiện theo dõi rõ ràng. |
| Block | Customers không thể chọn hoặc mua một variant quan trọng, lịch sử đơn hàng gây hiểu sai, đường dẫn ưu tiên bị lỗi hoặc dữ liệu riêng đã nằm trong phạm vi không thể sử dụng. | Chưa phê duyệt vận hành cho hạng mục bị ảnh hưởng. |
Kiểm thử đại diện phải bộc lộ độ phức tạp thực tế của cửa hàng: một bản ghi Products có nhiều variations, một bản ghi Products nhạy với tồn kho, một đơn hàng có giảm giá hoặc Coupons, một hồ sơ Customers có lịch sử đáng chú ý, một bản ghi Categories đại diện có mức độ ưu tiên cao hoặc một collection ưu tiên, một hành trình bán hàng dùng SP Page Builder và một trường do phần tùy chỉnh hoặc các tích hợp quản lý. Sau đó, giai đoạn di chuyển dữ liệu với phạm vi rộng hơn cần chứng minh toàn bộ phạm vi, variants hiếm gặp, Orders cũ và ngoại lệ, Customers trùng hoặc guest cùng tất cả đường dẫn công khai ưu tiên.
Quyết định Pass cần được hỗ trợ bằng cả thông tin từ giao diện quản trị và kết quả trên storefront khi cả hai đều có ý nghĩa. Một bản ghi nhìn đúng trong EasyStore dashboard nhưng không hoạt động qua danh sách Products, bộ lọc, cart, tài khoản hoặc checkout không thể được xem là Pass.
Xác thực lại sau các hoạt động EasyStore về sau và với đầu ra đã thống nhất
Thông tin kiểm chứng cũng phải giữ được mối liên hệ giữa dữ liệu đã thay đổi và chức năng EasyStore/Joomla tiếp tục sử dụng dữ liệu đó. Một hoạt động về sau không được phê duyệt chỉ vì số lượng bản ghi tăng đúng dự kiến.
Phạm vi xác thực lại phải tương xứng với phần đã thay đổi.
| Hành động về sau | Phạm vi xác thực lại với EasyStore |
|---|---|
| tiếp tục với cấu hình đã được chấp nhận | Xác nhận Products, variants, Customers, Orders và Blog Posts phát sinh sau vẫn tuân theo cách chuyển trường đã được chấp nhận và tiếp tục xuất hiện đúng qua Categories, collections, bộ lọc, menus và nội dung SP Page Builder. |
| tiếp tục với cấu hình đã điều chỉnh | Kiểm tra lại bộ lọc, cách chuyển trường, lựa chọn loại dữ liệu, cách xử lý variants, Customers, nội dung và các đường dẫn storefront bị ảnh hưởng bởi thay đổi. |
| tạo một kết quả di chuyển dữ liệu mới riêng biệt | Xem kết quả này như một bộ thông tin kiểm chứng mới và lặp lại các kiểm thử đại diện, kiểm tra phạm vi rộng hơn, routes, phần trình bày và quyết định vận hành có liên quan. |
Với những điều chỉnh đã được thống nhất trong phạm vi được hỗ trợ, hãy xác nhận quy tắc lọc, cách chuyển trường, cấu hình hoặc đầu ra cụ thể bằng các bản ghi được nêu rõ. Với phần xử lý riêng, cần xác nhận trường tùy chỉnh, phép biến đổi, dữ liệu extension, mã định danh bên ngoài hoặc quan hệ đặc biệt đã thống nhất. Thiết kế bằng Page Builder và phần triển khai trên đích vẫn là công việc riêng trừ khi được nêu rõ trong phạm vi.
Kết luận
Xác thực EasyStore by JoomShaper phải chứng minh dữ liệu sau di chuyển dữ liệu có thể hoạt động như dữ liệu thương mại bên trong website Joomla. Products, variants, Categories, Customers, Orders, refunds, Coupons, tồn kho, thuế, vận chuyển, bối cảnh thanh toán, các đường dẫn checkout, Joomla menus, phần trình bày SP Page Builder và dữ liệu riêng đều ảnh hưởng đến quyết định có thể đưa cửa hàng vào vận hành hay chưa.
Quy trình xác thực tốt nhất dùng các mẫu đại diện, tách dữ liệu đã di chuyển khỏi phần thiết lập trên đích, phân loại rõ những phát hiện cần xử lý đặc biệt và kiểm tra liệu kết quả có thực sự hỗ trợ bán hàng hay không. Kết quả chuyển đổi chỉ nên được phê duyệt khi EasyStore có ý nghĩa về mặt vận hành, không phải chỉ vì các bản ghi đã xuất hiện.
Câu hỏi thường gặp
Đối chiếu số lượng bản ghi có đủ để xác thực kết quả chuyển đổi sang EasyStore không?
Đối chiếu số lượng bản ghi không đủ để xác thực EasyStore. Số lượng không chứng minh variants vẫn có thể chọn, Categories và bộ lọc vẫn giúp Customers tìm Products, Customers còn kết nối với lịch sử hữu ích, Orders vẫn dễ hiểu hoặc các đường dẫn trên storefront Joomla hoạt động đúng.
Có cần xác thực bố cục SP Page Builder trong quá trình rà soát di chuyển dữ liệu không?
Cần xác thực khi các bố cục đó tạo danh sách Products, khối bán hàng, landing pages hoặc những đường dẫn ảnh hưởng đến hành vi mua. Tuy vậy, quá trình rà soát vẫn phải tách dữ liệu đã di chuyển khỏi phần triển khai và thiết kế trong Page Builder.
Những Orders nào hữu ích nhất khi xác thực EasyStore?
Hãy dùng Orders thông thường, Orders có nhiều variants, giảm giá, refund, nhạy với vận chuyển hoặc thuế, guest Orders và Orders giá trị cao, cùng các bản ghi có mã định danh bên ngoài hoặc trạng thái riêng.
Nên xác thực thanh toán, thuế và vận chuyển đang hoạt động như thế nào?
Hãy xem đây là cấu hình của Cửa hàng đích. Lịch sử đơn hàng chứng minh số tiền và nhãn đã từng được ghi nhận; các tình huống checkout hiện tại mới chứng minh phương thức và cách tính đang hoạt động đúng.
Khi nào việc xác thực EasyStore cần thông tin kiểm chứng cho phần xử lý riêng đã thống nhất?
Khi phạm vi đã được chấp nhận bao gồm dữ liệu extension không được hỗ trợ, trường tùy chỉnh cần xử lý riêng, mã định danh thuộc hệ thống bên ngoài, phép biến đổi theo quy tắc riêng hoặc quan hệ không tiêu chuẩn, hãy xác thực chính xác đầu ra đã thống nhất thay vì giả định các trường tiêu chuẩn đã bao quát yêu cầu.
Sau một hoạt động Di chuyển EasyStore về sau cần xác thực lại những gì?
Cần kiểm tra lại mọi cách chuyển dữ liệu và tình huống nghiệp vụ bị ảnh hưởng. Nếu tiếp tục với cấu hình không đổi, có thể tập trung vào kiểm thử hồi quy cho phần mới; nếu cấu hình thay đổi hoặc tạo một kết quả di chuyển dữ liệu mới, cần thiết lập phạm vi xác thực rộng hơn làm mốc mới.