Next-Cart

Nếu dự án chọn X-Cart làm Nền tảng đích, công tác chuẩn bị phải bắt đầu từ đúng thế hệ X-Cart đang dùng ở nguồn và tập module thực tế được cài đặt. Hai cửa hàng X-Cart có thể khác nhau đáng kể theo phiên bản, edition/package, lịch sử nâng cấp và thế hệ module. Thuộc tính Products có thể đóng vai trò thông số kỹ thuật, giá trị khách hàng lựa chọn hoặc chiều dùng để hình thành biến thể. Cửa hàng cũ có thể dùng cấu trúc biến thể Products đời trước, trong khi môi trường mới hơn dùng mô hình variation khác cùng module hoặc API khác. Nhóm thành viên, dữ liệu multi-vendor, module tùy chỉnh và tích hợp bên ngoài tiếp tục làm thay đổi ý nghĩa của từng bản ghi Products, Customers hoặc Orders.

Mục tiêu của giai đoạn chuẩn bị là mô tả cửa hàng thực tế, không phải một schema X-Cart chung được giả định. Mỗi hạng mục sẵn sàng cần xác định hành động, người phụ trách, tài liệu hoặc dữ liệu dùng để đối chiếu và điều kiện được xem là sẵn sàng. Đây là cơ sở kiểm soát cho việc cấu hình dự án chuyển đổi.

Xác định phiên bản X-Cart, quyền truy cập và nguồn gốc module

Ghi lại chính xác phiên bản X-Cart, edition/package, lịch sử nâng cấp, module đang hoạt động, module tùy chỉnh, theme, cấu hình Storefront hoặc marketplace, thế hệ API và môi trường hosting. Nguồn gốc phiên bản đặc biệt quan trọng khi catalog từng trải qua thay đổi giữa các mô hình biến thể Products, thay module hoặc có lần di chuyển cơ sở dữ liệu riêng trước đây.

Hành động Người phụ trách Dữ liệu/tài liệu đối chiếu Điều kiện sẵn sàng
Xác định chính xác phiên bản X-Cart và lịch sử cập nhật Chủ sở hữu kỹ thuật Ảnh giao diện quản trị, thông tin package, ghi chú nâng cấp Thế hệ nguồn và các lần nâng cấp đã biết được ghi nhận.
Kiểm kê module đang hoạt động và không còn hoạt động Quản trị viên cửa hàng hoặc developer Danh sách module kèm tác giả, phiên bản, trạng thái và mục đích Mỗi module quan trọng với hoạt động kinh doanh đều có người chịu trách nhiệm.
Xác định mô hình biến thể Products đang dùng Chủ sở hữu catalog và kỹ thuật Trạng thái module, bản ghi Products đại diện, vị trí dữ liệu liên quan Mô hình variation/variant đang hoạt động được xác định rõ.
Xác nhận kết nối nguồn và quyền truy cập file Chủ sở hữu hosting hoặc kỹ thuật Trạng thái truy cập, allowlist hoặc ghi chú xác thực Đúng bản cài đặt nguồn có thể truy cập.
Ghi nhận theme và các lớp code tùy chỉnh Developer hoặc agency Tên theme, đường dẫn module riêng, override, ghi chú triển khai Có thể phân biệt phần hiển thị và hành vi riêng khỏi bản ghi cốt lõi.
Ghi nhận API và luồng đồng bộ Chủ sở hữu tích hợp Phiên bản API, người giữ credentials, danh sách webhook hoặc scheduled job Hệ thống bên ngoài và mã bản ghi liên quan đã được xác định.

Không nên suy ra cấu trúc hiện tại của cửa hàng từ tài liệu dự án cũ hay hóa đơn module. Danh sách module đang chạy, cơ sở dữ liệu, cây code và các bản ghi đại diện phải khớp nhau.

Chuẩn bị Products, class, thuộc tính và biến thể

Khi chuẩn bị catalog X-Cart, cần tách bản ghi Products gốc, class của Products, định nghĩa thuộc tính, giá trị thuộc tính, giá trị khách hàng có thể chọn, thông số mô tả và biến thể có thể mua. Một thuộc tính tên “Color” có thể chỉ là thông tin mô tả ở một bản ghi Products nhưng lại là chiều tạo biến thể với SKU, giá, tồn kho, trọng lượng hoặc hình ảnh riêng ở Products khác.

Tạo danh mục catalog gồm ID Products, SKU, tên, trạng thái, loại Products khi có liên quan, liên kết Categories, class của Products, thuộc tính, biến thể, giá, tồn kho, trọng lượng, hình ảnh, file, nhóm thành viên, tax class, quyền sở hữu vendor/seller nếu có và mã định danh bên ngoài.

Mẫu cấu trúc ở nguồn Hành động chuẩn bị Dữ liệu/tài liệu đối chiếu Điều kiện sẵn sàng
Thuộc tính ở cấp class Ghi lại class, nhóm thuộc tính, kiểu, giá trị cho phép và Products được gán Export class và thuộc tính Có thể tách định nghĩa dùng chung khỏi giá trị riêng của từng Products.
Thuộc tính hoặc thông số thông thường Xác định giá trị dùng để mô tả, lọc hay cho khách nhập Bản ghi Products đại diện và ảnh storefront Thông số không bị nhầm thành biến thể có thể bán.
Chiều tạo biến thể có thể chọn Ghi nhận thuộc tính tạo biến thể và mọi tổ hợp đang hoạt động Manifest biến thể kèm SKU, tồn kho, giá, trọng lượng, hình ảnh Mỗi tổ hợp có thể bán có danh tính ổn định.
Cấu trúc biến thể Products đời cũ Ghi lại thế hệ module, trạng thái nâng cấp và bản ghi biến thể Dữ liệu module và ID Products đại diện Cấu trúc cũ và hiện tại không bị trộn âm thầm.
Products có file hoặc giao hàng số Ghi nhận tham chiếu file và quy tắc truy cập Danh sách Products/file và Orders đại diện File và quan hệ mua hàng lịch sử có thể truy xuất.
Products bị giới hạn theo nhóm thành viên hoặc vendor Ghi lại quan hệ truy cập/quyền sở hữu Ma trận nhóm thành viên/vendor Quyền hiển thị hoặc sở hữu được tài liệu hóa ngoài bản ghi Products.

Chỉ chuẩn hóa tên thuộc tính sau khi chủ sở hữu catalog xác nhận hai giá trị thực sự cùng ý nghĩa. Class dùng chung có thể làm một thay đổi sai lan sang nhiều Products.

Chuẩn bị Categories, điều hướng, quyền theo nhóm thành viên và phạm vi catalog

Categories, menu, class của Products, nhóm thành viên, vendor và phần hiển thị storefront đều có thể ảnh hưởng cách khách hàng tìm thấy Products. Hãy chuẩn bị cấu trúc Categories và liên kết Products, nhưng không mặc định rằng chỉ cần giữ quan hệ Categories là đủ để tái tạo điều hướng hoặc quyền truy cập.

Với cửa hàng dùng nhóm thành viên, ghi rõ Products, Categories, mức giá, nội dung hoặc chức năng tài khoản nào phụ thuộc vào nhóm. Với môi trường marketplace hoặc multi-vendor, ghi lại quyền sở hữu vendor, mã riêng của vendor, Products của seller, commission hoặc tham chiếu settlement khi có, cùng quan hệ giữa vendor và Orders.

Hạng mục catalog Người phụ trách Dữ liệu/tài liệu đối chiếu Điều kiện sẵn sàng
Cấu trúc Categories Chủ sở hữu catalog Danh sách cha-con và liên kết Products Categories cần giữ có mục đích và bản ghi cha rõ ràng.
Điều hướng và menu Chủ sở hữu storefront Ảnh menu và danh sách đích Cách menu hiển thị được tách khỏi dữ liệu Categories.
Class của Products Kiến trúc sư catalog Bản đồ class-Products và class-thuộc tính Có thể nhìn thấy quan hệ kế thừa thuộc tính dùng chung.
Hạn chế theo nhóm thành viên Chủ sở hữu B2B hoặc tài khoản Ma trận nhóm thành viên-Products/Categories/giá Ảnh hưởng đến quyền truy cập và giá đã rõ.
Phạm vi vendor hoặc seller Chủ sở hữu marketplace Bản ghi vendor-Products và vendor-Orders đại diện Quyền sở hữu seller không bị gộp thành manufacturer hoặc brand.

Chuẩn bị Customers, nhóm thành viên, địa chỉ và Orders

Dữ liệu Customers trên X-Cart có thể gồm tài khoản người dùng, địa chỉ, nhóm thành viên, vai trò, trường hồ sơ, trạng thái tài khoản, lựa chọn marketing, hồ sơ vendor và mã bên ngoài. Cần tách danh tính đăng nhập khỏi vai trò Customers, nhân viên, quản trị viên, vendor hoặc nhóm thành viên.

Khi chuẩn bị Orders, giữ các thông tin tại thời điểm đặt hàng như mô tả Products, SKU, thuộc tính, lựa chọn biến thể, giá, giảm giá, thuế, vận chuyển, nhãn thanh toán, trạng thái, ghi chú, shipment, refund, return, ngữ cảnh vendor và mã tham chiếu bên ngoài nếu có. Đồng thời ghi nhận module nào tạo thêm chi tiết trong Orders, phụ phí, subscription, transaction thanh toán, dữ liệu xử lý đơn hàng hoặc settlement marketplace.

Nhóm bản ghi Hành động chuẩn bị Dữ liệu/tài liệu đối chiếu Điều kiện sẵn sàng
Người dùng và Customers Phân loại Customers, quản trị viên, vendor và các vai trò khác Danh mục tài khoản-vai trò Không gộp tài khoản chỉ vì dùng chung một bảng.
Nhóm thành viên Ghi lại ý nghĩa hiện tại và ý nghĩa lịch sử Danh sách nhóm và Customers đại diện Cách catalog hoạt động hoặc giá được áp dụng theo nhóm có người chịu trách nhiệm.
Địa chỉ Tách địa chỉ hồ sơ khỏi snapshot trong Orders Bản ghi địa chỉ Customers và Orders đại diện Địa chỉ lịch sử vẫn có thể hiểu đúng.
Trạng thái Orders Ghi tên trạng thái, ý nghĩa quy trình và phụ thuộc module Bản đồ trạng thái và Orders đại diện Có thể hiểu trạng thái lịch sử mà không cần màu/icon từ giao diện quản trị cũ.
Chi tiết mặt hàng và tổng tiền Bao gồm giá trị biến thể, giảm giá, thuế, phí, vận chuyển và dòng do module tạo Chi tiết Orders đại diện Có thể tái dựng giao dịch từ dữ liệu lịch sử.
Mã định danh bên ngoài Ghi lại mã thanh toán, ERP, marketplace, shipment hoặc kế toán Sổ theo dõi mã định danh Hệ thống tiếp tục vận hành có thể tìm đúng bản ghi.

Không nên “làm sạch” lịch sử đơn hàng bằng cách thay tên Products hoặc thuộc tính cũ bằng giá trị catalog hiện tại. Snapshot tại nguồn là một phần của dữ liệu cần giữ để giải thích giao dịch.

Kiểm kê module, code riêng, bảng tùy chỉnh và hệ thống bên ngoài

Module X-Cart có thể mở rộng hoặc thay đổi cấu trúc dữ liệu cốt lõi, tạo bảng cơ sở dữ liệu, thay đổi hành vi model, cung cấp API resource, tạo trường hoặc điều khiển phần hiển thị storefront. Các thế hệ X-Cart hiện tại và cũ cũng dùng framework và đường dẫn module khác nhau. Vì vậy, cần lập sổ theo dõi quyền sở hữu thay vì chỉ giữ một danh sách module đã cài.

Tác động của module Dữ liệu cần chuẩn bị Điều kiện sẵn sàng
Trường Products hoặc Customers Khóa trường, kiểu dữ liệu, đối tượng sở hữu, ID đại diện Giá trị có chủ sở hữu đích hoặc quyết định loại trừ rõ.
Phần mở rộng biến thể hoặc tồn kho Bản ghi tổ hợp, nguồn tồn kho, mã SKU bên ngoài Danh tính có thể bán và hệ thống sở hữu tồn kho đã rõ.
Subscription, booking, bundle hoặc bản ghi dịch vụ Quan hệ với Products cha, Customers, Orders và lịch thực hiện Bản ghi chuyên biệt không bị rút gọn thành metadata Products.
Module marketplace Quan hệ vendor, offer, commission, payout và Orders Dữ liệu marketplace được tách khỏi danh tính catalog cốt lõi.
Module thanh toán hoặc xử lý đơn hàng Tham chiếu transaction, shipment hoặc trạng thái lịch sử Dữ liệu lịch sử tách được khỏi cấu hình tương lai.
Code hoặc bảng tùy chỉnh Schema, quan hệ khóa, quy trình đang hoạt động, chủ sở hữu dữ liệu Đối tượng nghiệp vụ được mô tả, không chỉ tên bảng.
PIM, ERP, WMS, CRM hoặc marketplace bên ngoài Quyền sở hữu theo trường và mã ổn định Hệ thống tiếp tục giữ vai trò nguồn dữ liệu chính thức được nêu rõ.

Phân loại module thành: đang hoạt động và bắt buộc, đang hoạt động nhưng có thể thay thế, chỉ còn giá trị lịch sử, không hoạt động nhưng vẫn giữ dữ liệu cần thiết, hoặc đã lỗi thời. Một module không còn hoạt động vẫn có thể sở hữu bản ghi cần thiết để giải thích lịch sử đơn hàng.

Chuẩn bị nội dung, media, URL và tài sản storefront

Nội dung trên X-Cart có thể gồm mô tả Products/Categories, Pages tĩnh hoặc CMS Pages, Blog Posts nếu module cung cấp, menu, banner, label, bản dịch, email template, theme block và trang do module tạo. Hãy chuẩn bị nội dung theo chủ sở hữu thay vì xem toàn bộ text hiển thị như một file CMS chung.

Ghi lại các route quan trọng của Products, Categories, nội dung, nhóm thành viên, vendor và module. Với mỗi route, lưu canonical path, ngôn ngữ/storefront áp dụng, mức độ quan trọng về traffic, module tạo route và cách xử lý dự kiến ở đích. Theme hoặc module có thể tạo route không tương ứng với một bản ghi nội dung thông thường.

Chuẩn bị media và file gốc cùng quan hệ cơ sở dữ liệu. Ghi lại nơi lưu trữ bên ngoài, kích thước được tạo tự động, file gốc bị thiếu, đường dẫn phân biệt chữ hoa/thường và file được bảo vệ bởi quy tắc truy cập của module.

Tạo gói nguồn X-Cart có thể phục hồi

Với cửa hàng X-Cart Self-hosted, gói nguồn nên gồm bản sao lưu cơ sở dữ liệu, file ứng dụng và file public liên quan, thông tin môi trường, manifest module, ghi chú triển khai/nâng cấp, trạng thái quyền truy cập và danh sách thay đổi cấu trúc sau thời điểm chốt dữ liệu dùng làm đối chiếu.

Thành phần gói nguồn Người phụ trách Dữ liệu/tài liệu đối chiếu Điều kiện sẵn sàng
Cơ sở dữ liệu Quản trị cơ sở dữ liệu Bản dump có timestamp và ghi chú khả năng restore Bảng cốt lõi và bảng module đến từ cùng trạng thái cửa hàng.
File ứng dụng và public Chủ sở hữu kỹ thuật File archive hoặc cây source có thể truy cập Module, theme, media và file được bảo vệ đều có sẵn.
Môi trường Chủ sở hữu kỹ thuật Ghi chú PHP, database, queue, cache, storage và web server Có thể diễn giải các hành vi phụ thuộc phiên bản.
Manifest module Developer hoặc quản trị viên cửa hàng Danh sách module hoạt động/không hoạt động cùng phiên bản Có thể truy ngược đối tượng do module sở hữu.
Change log Chủ sở hữu dự án Thay đổi muộn sau thời điểm thu thập dữ liệu Products mới, module mới hoặc thay đổi schema không bị bỏ sót.

Chọn bộ bản ghi đại diện để kiểm thử chuyển đổi

Chuẩn bị manifest mẫu gồm ID nguồn, bản ghi module hoặc hệ thống bên ngoài liên quan, file media và các quan hệ dự kiến ở nguồn. Manifest được xem là sẵn sàng khi các trường hợp đã chọn đầy đủ, có thể truy vết và được giao cho người rà soát.

Nên bao gồm:

  • Products đơn giản và Products thuộc nhiều class khác nhau;
  • Products có thuộc tính mô tả, giá trị khách hàng nhập và biến thể đang hoạt động;
  • một trường hợp dùng cấu trúc biến thể cũ hoặc đã trải qua chuyển đổi giữa hai mô hình nếu cửa hàng có lịch sử này;
  • Products bị hạn chế theo nhóm thành viên hoặc do vendor sở hữu nếu có;
  • Customers có nhóm thành viên, nhiều địa chỉ, mã bên ngoài hoặc vai trò vendor;
  • Orders của khách không đăng nhập và Customers đã đăng ký, gồm variation, tổng tiền bất thường, refund, shipment và bản ghi do module tạo;
  • Categories, nội dung, media và route quan trọng;
  • một bản ghi từ module tùy chỉnh đang hoạt động và một quan hệ với hệ thống bên ngoài.

Áp dụng điều kiện sẵn sàng cuối cùng cho X-Cart

Câu hỏi sẵn sàng Kết quả bắt buộc
Nguồn gốc hệ thống đã rõ chưa? Phiên bản, edition/package, lịch sử nâng cấp, thế hệ module và môi trường đã được ghi nhận.
Ý nghĩa catalog đã đầy đủ chưa? Class, thuộc tính, biến thể, Categories, nhóm thành viên, vendor và media đều được thể hiện.
Tài khoản và Orders có thể hiểu đúng chưa? Vai trò, nhóm thành viên, địa chỉ, snapshot Orders, trạng thái và tham chiếu bên ngoài có chủ sở hữu.
Module và dữ liệu riêng đã được phân loại chưa? Bản ghi do module đang hoạt động hoặc lịch sử sở hữu đều có quyết định xử lý.
Nội dung và route đã được kiểm kê chưa? Đường public, route module, media và tài sản phần hiển thị đã được tài liệu hóa.
Gói nguồn có thể phục hồi chưa? Cơ sở dữ liệu và file tương ứng với cùng trạng thái cửa hàng.
Manifest mẫu có đủ tính đại diện chưa? Có trường hợp cốt lõi, phức tạp, legacy, module và hệ thống bên ngoài.

Những điểm chưa xác định quan trọng phải tiếp tục là quyết định mở và có người phụ trách. Không nên chốt giai đoạn chuẩn bị khi mô hình biến thể, chủ sở hữu module, quan hệ vendor hoặc mã định danh bên ngoài vẫn chưa được phân loại.

Kết luận

Chuẩn bị chuyển đổi sang X-Cart phụ thuộc trực tiếp vào nguồn gốc hệ thống. Phiên bản, thế hệ module, class của Products, thuộc tính, biến thể, nhóm thành viên, vendor, phần mở rộng Orders, module riêng và hệ thống bên ngoài quyết định bản ghi nào tồn tại và chúng liên kết ra sao.

Một gói nguồn có thể phục hồi cùng manifest dữ liệu đại diện cho phép cấu hình dự án chuyển đổi dựa trên cửa hàng thực tế thay vì một mô hình X-Cart giả định.

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

Vì sao phải ghi lại phiên bản X-Cart và thế hệ module?

Cấu trúc X-Cart và cách module được triển khai đã thay đổi qua nhiều thế hệ. Cùng một khái niệm storefront có thể được lưu qua module, đối tượng hoặc API khác nhau, vì vậy phiên bản đang chạy và tập module thực tế quyết định dữ liệu nào là nguồn đối chiếu chính xác.

Thuộc tính và variation của X-Cart có phải cùng một thứ không?

Không phải cùng một thứ. Thuộc tính có thể mô tả Products, thu thập giá trị khách nhập hoặc tham gia hình thành biến thể. Chỉ những quan hệ tạo ra danh tính SKU, tồn kho, giá, trọng lượng hoặc hình ảnh riêng mới nên được xem như danh tính biến thể.

Cần chuẩn bị gì cho nhóm thành viên X-Cart?

Ghi lại định nghĩa nhóm, Customers được gán, hạn chế Products/Categories, ảnh hưởng đến giá, quy tắc tài khoản và Orders đại diện. Chỉ có tên nhóm thành viên không đủ để giữ ý nghĩa thương mại hoặc quyền truy cập.

Có nên bỏ qua module X-Cart không còn hoạt động không?

Không nên mặc định bỏ qua. Module không còn hoạt động vẫn có thể sở hữu dữ liệu đơn hàng trước đây, trường Customers hoặc mã định danh bên ngoài. Cần xác nhận dữ liệu còn cần thiết hay không trước khi đánh dấu module là lỗi thời.

Manifest mẫu của X-Cart nên chứa gì?

Nên gồm Products đơn giản và theo class, thuộc tính và biến thể, nhóm thành viên hoặc vendor nếu có, Orders phức tạp, route quan trọng, bản ghi do module sở hữu và quan hệ với hệ thống bên ngoài. Mỗi trường hợp nên dùng đúng ID nguồn và dữ liệu liên quan để có thể truy vết.

Vì sao cần cả bản sao lưu cơ sở dữ liệu và file?

Cơ sở dữ liệu giữ bản ghi cốt lõi và module, còn file có thể chứa module, theme, media, tài sản tải xuống, cấu hình và code riêng. Gói nguồn đầy đủ cần cả hai từ cùng một trạng thái cửa hàng.