Khi EasyStore by JoomShaper được xem xét làm Nền tảng đích, mô hình dữ liệu cần được hiểu như sự kết hợp giữa một component thương mại chuyên biệt và các lớp danh tính, quyền truy cập, routing, Modules cùng Page Builder của Joomla. Products, biến thể, Categories, tags, thương hiệu, bộ sưu tập, Customers, Orders, Coupons, Reviews và các bản ghi thương mại thuộc EasyStore; trong khi Joomla và SP Page Builder có thể quyết định cách các bản ghi đó được truy cập và trình bày trên website.
Vì vậy, câu hỏi cốt lõi không phải một bản ghi ở nguồn có thể được chép sang trường có tên gần giống trên đích hay không. Dự án cần xác định đối tượng nào trong EasyStore phải sở hữu ý nghĩa đó, đồng thời quan hệ nào thuộc Joomla hoặc lớp trình bày cần được giữ tách biệt. Nền tảng nguồn có thể gộp Products, options, thông số, bộ sưu tập, điều hướng, landing pages, danh tính người mua và lịch sử giao dịch vào một mô hình; EasyStore lại phân chia các trách nhiệm này giữa bản ghi thương mại và các bản ghi dùng để xây dựng website.
EasyStore tách dữ liệu thương mại khỏi các lớp sở hữu của Joomla
EasyStore quản lý mô hình bán hàng cốt lõi, còn Joomla cung cấp framework website xung quanh. SP Page Builder có thể sử dụng dữ liệu EasyStore để xây dựng phần hiển thị storefront nhưng không trở thành nơi sở hữu tồn kho Products, danh tính Customers hoặc lịch sử đơn hàng.
| Lớp sở hữu | Những bản ghi thường nằm trong lớp này | Ý nghĩa khi chuyển sang EasyStore |
|---|---|---|
| Dữ liệu thương mại của EasyStore | Products, biến thể, giá, tồn kho, Categories, tags, thương hiệu, bộ sưu tập, Customers, Orders, Coupons, Reviews | Các bản ghi này tạo thành mạng quan hệ dữ liệu thương mại và cần giữ đúng liên kết nội bộ. |
| Joomla core | Users, Access Levels, menus, Modules, ngôn ngữ, media, aliases | Các bản ghi này có thể kiểm soát danh tính, khả năng truy cập, mức độ hiển thị và bối cảnh website mà không thay thế dữ liệu thương mại của EasyStore. |
| SP Page Builder | Bố cục trang và các thành phần hiển thị dữ liệu EasyStore | Lớp trình bày tham chiếu dữ liệu EasyStore nhưng không trở thành nguồn quản lý Products hoặc Orders. |
| Các kết nối thanh toán và vận chuyển | Gateway, carrier và tham chiếu giao dịch | Tham chiếu lịch sử thuộc Orders; hành vi vận hành trong tương lai thuộc kết nối đang hoạt động trên Nền tảng đích. |
| Extensions tùy chỉnh và các tích hợp | Trường bổ sung, webhooks, external IDs và workflow chuyên biệt | Cần xác định rõ thành phần sở hữu trước khi gán giá trị vào đối tượng đích. |
Cách phân chia này giúp tránh hai sai lầm thường gặp khi chuyển đổi mô hình dữ liệu: coi nội dung Joomla như dữ liệu thương mại, hoặc coi phần hiển thị do Page Builder tạo ra như thể đó là nơi chứa mô hình Products dùng làm cơ sở quản lý chính.
Products, variations và variants cần được chuyển theo quan hệ
Một bản ghi Products trong EasyStore có thể chứa title, alias, description, media, giá, cách áp dụng thuế, thông tin phục vụ vận chuyển, mã định danh, cách tồn kho được quản lý, Categories, tags, access và dữ liệu SEO. Khi variations được thêm vào, EasyStore tạo ra ý nghĩa thương mại ở cấp variant. Giá và tồn kho có thể chuyển khỏi bối cảnh Products cha sang phần variants của Products, nơi từng tổ hợp có thể mang giá, giảm giá, trọng lượng, SKU, mã chuẩn, số lượng, trạng thái sẵn bán và khả năng hiển thị riêng.
Nền tảng nguồn có thể biểu diễn cùng một mặt hàng bằng nhiều Products độc lập, một bản ghi Products có options, ma trận tổ hợp variants, configurable child records hoặc các trường tùy chỉnh. Trên đích, dự án phải xác định bản ghi nào trở thành Products cha và bản ghi nào trở thành variants trong EasyStore.
| Cấu trúc catalog ở nguồn | Câu hỏi khi biểu diễn trong EasyStore | Ý nghĩa có nguy cơ bị sai |
|---|---|---|
| Mỗi kích thước hoặc màu sắc là một bản ghi Products riêng | Có nên gom các bản ghi dưới một bản ghi Products cha và tạo variants hay không? | URL, Reviews, media, tồn kho và external IDs có thể bị nhân đôi hoặc gộp sai. |
| Products cha có child SKUs | Attributes nào của bản ghi con sẽ định nghĩa variation values của EasyStore? | Từng tổ hợp có thể mua có thể mất SKU, giá, tồn kho hoặc trạng thái hiển thị riêng. |
| Free-text option được lưu trên Orders | Giá trị đó là variation có thể bán hay metadata lịch sử của chi tiết mặt hàng trong Orders? | Lựa chọn của người mua có thể bị ép vào cấu trúc variant không phản ánh đúng nguồn. |
| Trường thông số Products | Giá trị nên trở thành Additional Data thay vì variation hay không? | Thông tin mô tả có thể bị hiểu nhầm thành lựa chọn mà Customers phải chọn khi mua. |
| Products có tồn kho chung nhưng options có tồn kho riêng | Cấp nào mới là nơi quản lý số lượng tồn kho chính? | Cửa hàng đích có thể đếm trùng hoặc cho phép mua tổ hợp thực tế đã hết hàng. |
Variations trong EasyStore không chỉ là nhãn hiển thị. Khi Products đã có variations, từng variant tạo ra từ các lựa chọn này có thể sở hữu thuộc tính thương mại riêng. Vì vậy, identifiers từ nguồn phải tiếp tục gắn với đúng cấp hàng hóa mà hệ thống bên ngoài, quy trình kho và Orders trong lịch sử dùng để nhận diện.
Additional Data, tags, thương hiệu, bộ sưu tập và Products liên quan phục vụ các mục đích khác nhau
EasyStore cung cấp nhiều cấu trúc để mô tả và nhóm Products. Additional Data có thể lưu thông số có cấu trúc. Tags hỗ trợ tìm kiếm và phân loại linh hoạt. Brands xác định thương hiệu hoặc nhà sản xuất. Categories tổ chức hệ thống catalog chính. Collections phục vụ nhóm Products theo mục đích merchandising. Quan hệ upsell và cross-sell liên kết một bản ghi Products với các bản ghi Products khác.
Không nên gộp các cấu trúc này thành một taxonomy chung.
| Cấu trúc EasyStore | Vai trò chính | Dữ liệu nguồn có thể phù hợp |
|---|---|---|
| Categories | Tổ chức catalog chính và gán Products | Categories hoặc departments ở nguồn có ý nghĩa điều hướng lâu dài |
| Tag | Nhãn linh hoạt hỗ trợ khám phá Products | Keywords, chủ đề, trường hợp sử dụng hoặc phân loại không theo cấp bậc |
| Brand | Danh tính thương hiệu hoặc nhà sản xuất của Products | Brand, vendor hoặc manufacturer khi ý nghĩa tương ứng |
| Collection | Nhóm Products được tuyển chọn cho merchandising | Nhóm theo chiến dịch, mùa vụ, bộ sưu tập nổi bật hoặc nhóm biên tập |
| Additional Data | Thông số mô tả Products | Thông số kỹ thuật, chất liệu, kích thước, khả năng tương thích hoặc dữ liệu mô tả |
| Quan hệ upsell/cross-sell | Liên kết Products với Products để hỗ trợ bán hàng | Products liên quan, Products bổ trợ, Products thay thế hoặc Products có giá bán cao hơn |
Một “collection” ở nguồn có thể thực chất là Categories, nhóm được tạo bởi quy tắc, landing page hoặc chiến dịch. Đích đến nên được chọn theo chức năng kinh doanh chứ không theo tên gọi. Nguyên tắc tương tự áp dụng với attributes: kích thước mà Customers có thể chọn thuộc cấu trúc variation, còn thông số kỹ thuật không thể chọn thuộc Additional Data hoặc trường mô tả phù hợp khác.
EasyStore Categories không phải Joomla Menu Items hoặc bố cục Page Builder
EasyStore Categories tổ chức Products trong mô hình thương mại. Joomla Menu Items làm cho pages có thể được truy cập và có thể xác định alias, route, access, ngôn ngữ và bối cảnh Template. SP Page Builder sắp xếp components và các khối EasyStore trên trang. Một landing page của storefront có thể đồng thời phụ thuộc vào cả ba lớp này.
| Khái niệm trên storefront | Thành phần sở hữu trong EasyStore | Quan hệ với Joomla hoặc lớp trình bày |
|---|---|---|
| Hệ thống phân cấp danh sách Products | Cây EasyStore Categories | Menu Item có thể đưa Customers đến route của Categories hoặc trang tuyển chọn. |
| URL Products | Alias Products và component routing của EasyStore | Bối cảnh menu của Joomla có thể ảnh hưởng đến đường dẫn công khai. |
| Campaign landing page | Tham chiếu đến Products hoặc Collection của EasyStore | Bố cục SP Page Builder có thể sắp xếp nội dung chiến dịch. |
| Nhãn điều hướng | Joomla Menu Item | Có thể trỏ đến EasyStore Categories, Collection, Products hoặc custom page. |
| Khối Products | Nguồn dữ liệu EasyStore | SP Page Builder kiểm soát vị trí và cách trình bày. |
Sự phân chia này đặc biệt quan trọng khi Nền tảng nguồn lưu điều hướng và phân nhóm catalog trong cùng một đối tượng. Chỉ tái tạo cây Categories chưa chắc tái tạo được điều hướng công khai. Ngược lại, chỉ sao chép bố cục trang có thể khiến Products bị tách khỏi Categories và Collection đang sở hữu quan hệ thật sự.
Customers và Joomla users có thể được liên kết nhưng không phải cùng một bản ghi
EasyStore có thể duy trì hồ sơ Customers và cho phép chuyển Joomla User hiện có thành hồ sơ Customers. Mối liên hệ này không làm hai khái niệm trở thành một. Joomla sở hữu danh tính đăng nhập, trạng thái tài khoản, nhóm người dùng và access. EasyStore sở hữu hồ sơ người mua và các quan hệ thương mại cần cho hoạt động storefront.
Nền tảng nguồn có thể chứa Customers đã đăng ký, khách mua không đăng nhập, administrators chưa từng mua hàng, hoặc Customers có lịch sử giao dịch dùng email khác với tài khoản hiện tại. Không nên chuẩn hóa tất cả thành một mô hình tài khoản nếu việc đó làm mất ý nghĩa lịch sử.
| Mô hình danh tính ở nguồn | Quyết định quan hệ trong EasyStore |
|---|---|
| Người mua đã đăng ký và có tài khoản tương đương Joomla | Liên kết hồ sơ Customers của EasyStore với đúng Joomla User khi cấu trúc đích hỗ trợ quan hệ này. |
| Khách mua không đăng nhập | Giữ thông tin người mua và địa chỉ cùng lịch sử đơn hàng mà không tạo tài khoản cố định ngoài nhu cầu thực tế. |
| Nhiều tài khoản nguồn dùng chung email | Quyết định có giữ riêng, hợp nhất hay cần external key để phân biệt. |
| Tài khoản nhân viên hoặc administrator | Giữ danh tính permissions tách khỏi trạng thái Customers trừ khi người đó cũng là người mua. |
| B2B contact thuộc một tổ chức | Không gộp ý nghĩa của tổ chức, contact, giá và permissions vào một hồ sơ Customers cơ bản. |
Joomla User Groups cũng cần được tách khỏi phân khúc thương mại. Một nhóm dùng cho permissions quản trị hoặc nội dung giới hạn truy cập không mặc nhiên tương đương với nhóm Customers, nhóm được hưởng giảm giá hoặc wholesale tier.
Orders giữ lại ảnh chụp giao dịch trong lịch sử, không phải cấu hình đang hoạt động
Một bản ghi Orders trong EasyStore đại diện cho giao dịch đã xảy ra. Ý nghĩa hữu ích có thể bao gồm danh tính Customers hoặc khách mua không đăng nhập, địa chỉ, Products và variants được chọn, số lượng, giá, giảm giá, thuế, vận chuyển, tham chiếu thanh toán, trạng thái, refund hoặc hủy Orders, ghi chú và thời gian. Đây là dữ liệu ghi lại những gì đã xảy ra tại thời điểm mua.
Không nên dùng Orders trong lịch sử để thay thế cấu hình hiện tại của Products, thuế, vận chuyển, thanh toán hoặc checkout. Nhãn vận chuyển trên đơn hàng cũ cho biết phương thức từng được sử dụng, không định nghĩa cấu hình carrier trên đích. Tham chiếu thanh toán giữ bối cảnh giao dịch, không cấu hình gateway.
| Quan hệ trong Orders | Ý nghĩa lịch sử cần duy trì |
|---|---|
| Tham chiếu đến Products hoặc variant | Mặt hàng có thể mua nào đã được mua, bao gồm source identifier khi cần |
| Mô tả mặt hàng và giá trị đã chọn | Tên mặt hàng và lựa chọn mà người mua nhìn thấy tại thời điểm giao dịch |
| Quan hệ Customers hoặc khách mua không đăng nhập | Ai đặt Orders và địa chỉ nào được sử dụng |
| Giá, giảm giá, thuế và tổng tiền | Giá trị thương mại tại thời điểm giao dịch, không phải kết quả tính lại theo quy tắc hiện tại |
| Tham chiếu vận chuyển và thanh toán | Phương thức và bối cảnh giao dịch được ghi cho đơn hàng đó |
| Trạng thái và dòng thời gian | Thông tin xác nhận diễn biến giao dịch cần cho hỗ trợ và báo cáo |
| Thông tin refund hoặc hủy | Thay đổi trong lịch sử so với giao dịch gốc |
Nếu Nền tảng nguồn lưu chi tiết mặt hàng trong Orders độc lập với bản ghi Products hiện tại, dữ liệu lịch sử vẫn phải đọc được ngay cả khi catalog đã thay đổi, SKU đã ngừng dùng hoặc cấu trúc variant đã được tổ chức lại.
Coupons, Reviews và các quan hệ khác cần có chủ sở hữu riêng
Coupons và Reviews có quan hệ với catalog và Customers nhưng không phải trường của Products. Một bản ghi Coupons có thể chứa điều kiện áp dụng, loại giảm giá, thời gian, mức sử dụng và quan hệ với Products, Categories hoặc Customers. Một bản ghi Reviews có thể liên kết Customers hoặc khách mua không đăng nhập với Products, rating, nội dung, trạng thái và thời gian.
Nếu coi các bản ghi này chỉ là nội dung trang trí, ý nghĩa quan hệ sẽ bị mất. Bản ghi Reviews không liên kết đúng Products sẽ trở thành bản ghi mồ côi. Bản ghi Coupons chỉ còn mã nhưng mất điều kiện có thể đại diện cho một quy tắc thương mại hoàn toàn khác. Wishlist, analytics event hoặc abandoned-cart record có thể thuộc khu vực khác của EasyStore hoặc hệ thống bên ngoài và không nên được suy ra từ dữ liệu Customers hay Orders cốt lõi.
SP Page Builder lưu quan hệ trình bày, không sở hữu dữ liệu thương mại
EasyStore có thể cung cấp Products và các thành phần thương mại cho bố cục SP Page Builder. Các khối Page Builder có thể hiển thị danh sách Products, tìm kiếm, Categories, bộ lọc, giá, Ratings, title, cart controls, wishlist, Reviews và các thành phần storefront khác. Những khối này tham chiếu dữ liệu thương mại; chúng không sở hữu tồn kho Products hoặc lịch sử đơn hàng.
Visual builder ở Nền tảng nguồn có thể nhúng tham chiếu catalog trực tiếp trong JSON hoặc bản ghi bố cục. Mô hình đích cần tách nội dung biên tập có thể tái sử dụng, cấu hình bố cục tĩnh và các tham chiếu động đến EasyStore.
| Thành phần Page Builder | Cách hiểu dữ liệu |
|---|---|
| Khối danh sách Products | Truy vấn hiển thị hoặc tham chiếu đến EasyStore Products |
| Khối Categories | Quan hệ hiển thị với EasyStore Categories |
| Khối price, rating, title hoặc thumbnail | Trường được render từ bối cảnh Products |
| Cart hoặc wishlist control | Thành phần tương tác trên storefront, không phải dữ liệu cart trong lịch sử |
| Static text hoặc image block | Nội dung trang có thể cần xử lý như một phạm vi nội dung riêng |
| Custom layout override | Phần triển khai trình bày, không phải loại dữ liệu thương mại tiêu chuẩn |
Cách phân chia này giúp Products và Categories tiếp tục giữ vai trò bản ghi thương mại chính, trong khi bố cục trang có thể được xây dựng lại hoặc chuyển đổi theo mô hình trình bày của đích.
Settings, các tích hợp và custom data cần được phân loại theo chủ sở hữu
Thiết lập EasyStore có thể định nghĩa thuế, checkout, thanh toán, vận chuyển, thông báo email, cách tồn kho được quản lý và quy tắc hiển thị. Các thiết lập này ảnh hưởng đến hoạt động mới nhưng không tương đương với Products, Customers hoặc Orders. Bản ghi lịch sử có thể chứa kết quả do các thiết lập cũ tạo ra mà không mang theo chính cấu hình sẽ vận hành trên đích.
Custom shipping carriers, payment các tích hợp, extensions do đội ngũ phát triển xây dựng, custom các trường trong cơ sở dữ liệu, webhooks và external-system identifiers có thể bổ sung thêm các lớp sở hữu. Mô hình đích cần xác định mỗi giá trị thuộc bản ghi EasyStore core, danh tính hoặc route Joomla, tham chiếu SP Page Builder, bản ghi các tích hợp hay external-system key.
| Dấu hiệu của dữ liệu riêng | Yêu cầu khi chuyển sang đích |
|---|---|
| ERP hoặc warehouse ID ở cấp variant | Giữ ID trên đúng biến thể có thể bán, không chỉ trên Products cha. |
| Trường Customers tùy chỉnh | Xác định giá trị thuộc EasyStore, dữ liệu Joomla User hay hồ sơ trong hệ thống bên ngoài. |
| Gateway transaction reference | Giữ cùng lịch sử đơn hàng và bối cảnh thanh toán tương ứng. |
| Shipment identifier riêng của carrier | Giữ cùng Orders hoặc quan hệ vận chuyển thực sự sử dụng mã đó. |
| Custom Page Builder data source | Xác định loại dữ liệu EasyStore được tham chiếu và cấu hình trình bày tách biệt. |
| Bảng dữ liệu do extension sở hữu | Xác định bản ghi cha, mục đích kinh doanh và chủ sở hữu trên đích trước khi chuyển dữ liệu. |
Vì vậy, một mô hình chuyển đổi EasyStore rõ ràng thực chất là bản đồ sở hữu: dữ liệu thương mại nằm trong EasyStore; đăng nhập và quyền truy cập nằm trong Joomla; cấu trúc trình bày nằm trong SP Page Builder hoặc lớp hiển thị tương ứng; external identifiers tiếp tục gắn với những bản ghi mà hệ thống kết nối sử dụng để nhận diện.
Kết luận
Chuyển dữ liệu sang EasyStore đòi hỏi nhiều hơn việc tạo Products và Customers. Products có thể chứa các bản ghi thương mại ở cấp variant; Categories, tags, thương hiệu, bộ sưu tập và thông số phục vụ các mục đích khám phá khác nhau; Joomla Users và EasyStore Customers có thể liên kết mà không trở thành cùng một đối tượng; Orders giữ ảnh chụp giao dịch trong lịch sử; còn bố cục SP Page Builder tham chiếu chứ không sở hữu dữ liệu thương mại.
Giữ rõ các ranh giới này giúp Cửa hàng đích hỗ trợ quản trị catalog, danh tính Customers, chăm sóc dựa trên lịch sử, trình bày storefront và duy trì hoạt động của các hệ thống được kết nối mà không gộp các lớp Joomla và EasyStore thành một tập bản ghi thiếu chủ sở hữu.
Câu hỏi thường gặp
Variations trong EasyStore có chỉ là options dùng để hiển thị không?
Variations trong EasyStore không chỉ là options dùng để hiển thị. Khi variations được tạo, variants của EasyStore có thể mang giá, giảm giá, cách áp dụng thuế, dữ liệu vận chuyển, SKU, mã Products chuẩn, tồn kho, trạng thái sẵn bán và khả năng hiển thị riêng. Nếu Nền tảng nguồn có các tổ hợp tương đương, chúng cần được xử lý như những bản ghi có thể bán với danh tính riêng.
Thông số Products có nên trở thành variations không?
Chỉ khi giá trị đó xác định một tổ hợp mà Customers thực sự có thể chọn để mua. Thông số chỉ dùng để mô tả nên được đưa vào Additional Data hoặc cấu trúc mô tả phù hợp khác để tránh tạo variants không có ý nghĩa thương mại.
EasyStore Categories có giống Joomla Menu Items không?
EasyStore Categories không giống Joomla Menu Items. EasyStore Categories tổ chức Products. Joomla Menu Items tạo điều hướng và bối cảnh route, đồng thời có thể trỏ đến Categories, Products, Collection hoặc Page Builder page.
Joomla User có thể liên kết với hồ sơ Customers trong EasyStore không?
Joomla User có thể liên kết với hồ sơ Customers trong EasyStore. EasyStore hỗ trợ chuyển Joomla User thành hồ sơ Customers, nhưng Joomla User vẫn là danh tính đăng nhập trong khi EasyStore quản lý hồ sơ thương mại và các quan hệ Customers.
Orders đã di chuyển có cấu hình thanh toán, vận chuyển hoặc thuế không?
Orders đã di chuyển không cấu hình thanh toán, vận chuyển hoặc thuế cho hoạt động mới. Orders giữ bối cảnh giao dịch trong lịch sử. Cách thanh toán, vận chuyển, thuế và checkout hoạt động trong tương lai thuộc thiết lập EasyStore cùng các tích hợp đang hoạt động trên đích.
Bố cục storefront trong SP Page Builder nên được xử lý như thế nào?
Cần tách thành nội dung trang tĩnh, cấu hình trình bày và các tham chiếu đến loại dữ liệu EasyStore. Dữ liệu Products và Orders phải tiếp tục được quản lý trong EasyStore ngay cả khi Page Builder quyết định cách các thành phần storefront xuất hiện.