Bagisto không xem catalog thương mại điện tử như một tập hợp phẳng gồm Products và các trường tùy chỉnh. Kiến trúc dựa trên Laravel tách các loại Products, attributes, attribute families, Categories, channels, locales, currencies, inventory sources, các nhóm Customers, Orders, CMS Pages, dữ liệu marketing, packages, APIs và những lớp thương mại bổ sung như Marketplace hoặc B2B thành các vùng trách nhiệm khác nhau. Một giá trị từ Cửa hàng nguồn chỉ thực sự hữu ích trong Bagisto khi được đưa vào đúng cấu trúc đang sở hữu ý nghĩa thương mại của giá trị đó.
Điều này làm thay đổi phạm vi di chuyển dữ liệu. Một giá trị kích thước có thể chỉ là thông tin mô tả, có thể là attribute phục vụ filtering, hoặc có thể tham gia trực tiếp vào quan hệ configurable Products. Một con số tồn kho có thể thuộc một inventory source cụ thể chứ không phải Products trên toàn hệ thống. Một storefront có thể tương ứng với một channel có Categories gốc, locale, currency, theme và inventory riêng. Một company account hoặc seller có thể thuộc package B2B/Marketplace thay vì mô hình Customers cốt lõi.
Vì vậy, câu hỏi trung tâm không phải Bagisto có một trường cùng tên hay không. Cần xác định Cửa hàng đích có thể biểu diễn đúng quan hệ hay không: bản ghi thuộc về cấu trúc nào, giá trị đó chi phối điều gì và những bản ghi nào phải tiếp tục liên kết để ý nghĩa kinh doanh không bị mất sau khi di chuyển.
Bagisto phân chia dữ liệu theo các lớp trách nhiệm thương mại
Bagisto kết hợp dữ liệu thương mại cốt lõi với cấu hình và các cấu trúc do extensions/packages quản lý. Hai giá trị nằm cạnh nhau trong file export của Cửa hàng nguồn có thể thuộc hai cấu trúc đích hoàn toàn khác nhau. Danh tính Products thuộc catalog. Những attributes được dùng cho Products phụ thuộc attribute family. Phạm vi storefront thuộc channels. Quyền sở hữu tồn kho thuộc inventory sources. Phân khúc Customers thuộc các nhóm Customers hoặc lớp B2B/Marketplace được cài đặt. Phần hiển thị có thể thuộc CMS Pages, theme hoặc cửa hàng Headless.
| Ý nghĩa phía Cửa hàng nguồn | Cấu trúc Bagisto có thể sở hữu | Hệ quả khi chuyển đổi |
|---|---|---|
| Mặt hàng có thể bán | Bản ghi Products với loại Products được xác định | Loại Products quyết định quan hệ con, lựa chọn mua, cách xử lý đơn hàng và cách áp dụng giá. |
| Thông số Products | Attribute được tổ chức qua attribute family | Một giá trị text hiển thị không tự động trở thành dữ liệu có thể filtering, so sánh hoặc tái sử dụng. |
| Store, market hoặc domain | Channel gắn với locale, currency, Categories gốc, theme và inventory | Ngữ cảnh storefront phải tiếp tục gắn với đúng catalog và ngữ cảnh bản địa hóa. |
| Số lượng tại warehouse | Quan hệ inventory source và số lượng | Gộp thành tồn kho toàn cục có thể làm mất quyền sở hữu theo vị trí. |
| Phân khúc Customers | Nhóm Customers hoặc cấu trúc account do package quản lý | Ý nghĩa giá và quyền truy cập có thể không phù hợp với một trường dữ liệu đơn lẻ trong bản ghi Customers. |
| Giao dịch lịch sử | Orders cùng chi tiết mặt hàng, totals, addresses, invoices, shipments, refunds và transactions | Chỉ giữ số lượng Orders không thể duy trì lịch sử thương mại. |
| Chức năng thương mại tùy chỉnh | Package Bagisto, module tùy chỉnh, bản ghi do API quản lý hoặc hệ thống bên ngoài | Chỉ liên kết các trường dữ liệu cốt lõi là chưa đủ nếu một thành phần khác sở hữu quan hệ. |
Chính sự phân lớp này khiến cách mapping một trường nguồn sang một trường đích không phải lúc nào cũng đáng tin cậy. Cùng một giá trị có thể cần đích khác nhau tùy giá trị đó ảnh hưởng đến lựa chọn Products, quản trị catalog, localization, inventory, cách phục vụ Customers, reporting hay khả năng tiếp tục kết nối với hệ thống bên ngoài.
Các loại Products xác định quan hệ có thể bán
Bagisto hỗ trợ nhiều loại Products như simple, configurable, virtual, bundle, grouped, downloadable và booking-oriented. Loại Products không chỉ là nhãn trong khu vực quản trị. Cấu trúc này xác định thứ đang được bán, có quan hệ Products con hay liên kết hay không, những trường nào có ý nghĩa, cách giá và tồn kho được hiểu, cũng như khách hàng thực sự lựa chọn điều gì.
Ví dụ, Products cha có các SKU con theo màu và kích thước có thể trở thành configurable Products, trong đó từng variation có SKU, giá, số lượng, hình ảnh hoặc khả năng hiển thị riêng. Một kit chỉ phù hợp với bundle khi cấu trúc component và quy tắc lựa chọn tương ứng với cách Bagisto quản lý bundle. Grouped Products là nhóm các Products có thể bán độc lập, không phải một SKU duy nhất sở hữu toàn bộ tồn kho. Downloadable Products cần quan hệ với file và quyền truy cập. Booking-oriented Products còn bổ sung lịch và khả năng đặt chỗ, vì vậy không thể chỉ biểu diễn bằng options thông thường.
| Mô hình nguồn | Quan hệ cần phân biệt trong Bagisto | Ý nghĩa đối với phạm vi |
|---|---|---|
| Products cha và các SKU con | Configurable Products và variations | Nội dung của Products cha và giá trị thương mại của Products con không được gộp thành một bản ghi. |
| Kit có component tùy chọn | Bundle Products và lựa chọn bundle | Cách chọn component, số lượng và giá có thể cần chuyển thành cấu trúc khác. |
| Nhóm merchandising gồm các mặt hàng độc lập | Grouped Products và Products liên kết | Mỗi Products liên kết vẫn có thể bán và quản lý tồn kho độc lập. |
| Dịch vụ không vật lý | Virtual Products hoặc cấu trúc dịch vụ do package quản lý | Ý nghĩa shipping và xử lý đơn hàng khác Products vật lý. |
| Mặt hàng số | Downloadable Products cùng files, links và quy tắc truy cập | Quan hệ file tách biệt với phần mô tả Products. |
| Dịch vụ theo lịch hoặc thuê | Booking Products hoặc cấu trúc package tùy chỉnh | Quan hệ lịch và tài nguyên không thể chỉ biến thành options dạng text. |
Quyết định về loại Products cũng ảnh hưởng đến lịch sử đơn hàng. Chi tiết mặt hàng đã mua cần tiếp tục dễ hiểu ngay cả khi Cửa hàng đích thể hiện Products khác Cửa hàng nguồn. Chỉ giữ tên Products mà mất variation, bundle selection, download hoặc booking context sẽ tạo lịch sử đơn hàng có bản ghi nhưng thiếu ý nghĩa.
Attributes và attribute families quản lý ý nghĩa của catalog
Attributes trong Bagisto tạo dữ liệu Products có cấu trúc. Attribute families xác định nhóm attributes phù hợp với từng lớp Products. Vì vậy, không nên sao chép toàn bộ các trường tùy chỉnh của catalog cũ vào một mô hình Products duy nhất.
Một trường dùng để filtering cần được xử lý khác trường chỉ phục vụ tham chiếu nội bộ. Giá trị tạo lựa chọn configurable phải tách khỏi thông số mô tả. Tiêu đề theo locale, giá, SKU duy nhất, cờ Boolean dùng cho storefront và thông số kỹ thuật multi-select có loại dữ liệu, validation, indexing và phạm vi channel/locale khác nhau.
Thiết kế attribute family vì thế là bước chuyển các quy ước catalog của Cửa hàng nguồn thành schema có kiểm soát trên Nền tảng đích. Doanh nghiệp bán apparel, machinery, tài liệu tải xuống và dịch vụ đặt lịch có thể cần các families khác nhau vì mỗi nhóm Products sử dụng attributes và quan hệ thương mại khác nhau.
| Cách trường nguồn được sử dụng | Cách diễn giải trong Bagisto | Điều phải duy trì |
|---|---|---|
| Khách hàng chọn giá trị | Configurable attribute hoặc lựa chọn theo loại Products | Giá trị được chọn phải dẫn tới đúng variation hoặc mặt hàng có thể mua tương ứng. |
| Khách hàng filtering theo giá trị | Attribute của Products có thể filtering | Giá trị phải đủ chuẩn hóa để filtering có ý nghĩa. |
| Nhân sự so sánh Products theo giá trị | Attribute có cấu trúc/phục vụ so sánh | Thông tin tương đương không bị chôn trong mô tả text. |
| Trường chỉ áp dụng cho một nhóm Products | Attribute được gắn cho family cụ thể | Products không liên quan không bị ép dùng schema quá lớn. |
| Giá trị khác nhau theo locale hoặc channel | Dữ liệu theo locale/channel khi cấu trúc hỗ trợ | Đúng storefront nhận đúng giá trị. |
| Metadata dùng cho tích hợp | Attribute tùy chỉnh, bản ghi package hoặc external identifier | Identifier vận hành không bị biến thành nội dung storefront. |
Sự phân biệt này tránh một sai lệch phổ biến: coi mọi option, specification, tag, trường do app quản lý và internal code của Cửa hàng nguồn là cùng một loại attribute. Bagisto có thể lưu catalog phong phú, nhưng giá trị của sự linh hoạt đó phụ thuộc vào việc từng dữ liệu được đặt đúng family và đúng chức năng.
Categories, channels, locales và inventory sources cùng tạo phạm vi storefront
Categories tổ chức Products, nhưng quan hệ channel quyết định catalog và ngữ cảnh localization mà storefront sử dụng. Một channel có thể gắn với hostname, Categories gốc, locales, currencies, theme và inventory sources. Vì vậy, một store theo khu vực, website theo ngôn ngữ hay storefront theo business unit ở Cửa hàng nguồn có thể cần nhiều hơn một cây Categories để thể hiện đúng trong Bagisto.
Categories có thể phục vụ điều hướng khách hàng, merchandising landing pages, phân loại nội bộ hoặc chỉ là cấu trúc kế thừa. Bagisto nên nhận những quan hệ còn hữu ích, không nhất thiết mọi nhãn Categories cũ. Categories gốc của channel đặc biệt quan trọng vì cấu trúc này xác định điểm bắt đầu hierarchy catalog cho storefront đó.
Inventory sources tạo thêm một lớp quyền sở hữu. Tồn kho của một bản ghi Products có thể phân bổ ở nhiều địa điểm. Do đó, số lượng nguồn cần được đọc cùng warehouse, branch, supplier, pickup hoặc ngữ cảnh xử lý đơn hàng. Cộng mọi địa điểm thành một con số có thể giữ tổng tồn kho nhưng làm mất khả năng xác định nơi hàng thực sự có sẵn.
| Lớp phạm vi | Quan hệ trong Bagisto | Điểm dễ nhầm từ nguồn |
|---|---|---|
| Categories | Hierarchy cha-con, Products assignment, nội dung theo locale và ý nghĩa URL | Categories nguồn có thể trộn điều hướng, SEO và nhóm nội bộ. |
| Channel | Domain, Categories gốc, locale, currency, theme và inventory context | Một “store” nguồn có thể thực tế là market, language, brand hoặc business unit. |
| Locale | Giá trị Products, Categories và nội dung được dịch | Nguồn có thể lưu ngôn ngữ thành bản ghi lặp hoặc trường riêng thay vì translation liên kết. |
| Currency | Cách hiển thị và ngữ cảnh thương mại | Currency của lịch sử đơn hàng phải tách khỏi cấu hình channel hiện tại. |
| Inventory source | Tồn kho thuộc địa điểm | Một số lượng Products có thể che giấu nhiều warehouses hoặc stock pools. |
Một bản ghi Products có thể đã di chuyển đúng nhưng vẫn không bán đúng nếu được gắn sai Categories gốc, không xuất hiện trong channel dự kiến, thiếu giá trị theo locale hoặc thuộc inventory source không phù hợp. Đây là lỗi quan hệ dữ liệu dù toàn bộ bản ghi Products đều hiện diện.
Customers, các nhóm Customers, Marketplace sellers và B2B accounts là những danh tính khác nhau
Customers cốt lõi của Bagisto lưu danh tính, thông tin liên hệ, addresses và quan hệ nhóm. Các nhóm Customers có thể ảnh hưởng đến cách phục vụ thương mại, gồm giá theo nhóm và điều kiện áp dụng rules. Tuy nhiên, Marketplace sellers, B2B companies, company users, approval roles, requisition lists, quotations và purchase Orders có thể thuộc các packages tùy chọn thay vì Customers cốt lõi.
Một tag nguồn như wholesale, dealer, distributor, employee, tax-exempt, approved buyer hoặc Marketplace seller phải được hiểu theo mục đích. Một số thuộc nhóm Customers cốt lõi. Một số đại diện company account, seller organization, permission role, credit relationship hoặc phân loại bên CRM. Gộp tất cả vào một trường text giữ lại nhãn nhưng làm mất quan hệ đã khiến nhãn đó có giá trị vận hành.
| Danh tính nguồn | Câu hỏi về đích trong Bagisto | Quan hệ cần duy trì |
|---|---|---|
| Người mua cá nhân | Customers cốt lõi và addresses | Danh tính, liên hệ, tài khoản và lịch sử đơn hàng. |
| Phân khúc thương mại | Nhóm Customers hoặc quan hệ giá | Phân khúc phải khác với tag tự do. |
| Người mua thuộc doanh nghiệp | B2B company và company-user khi package tương ứng được dùng | Users gắn với đúng company, role và ngữ cảnh thương mại. |
| Marketplace seller | Seller/vendor do package Marketplace quản lý | Products, Orders, commissions, payouts và users của seller giữ đúng liên kết. |
| Account trong CRM/ERP | Customers cùng external identifier | Cửa hàng đích có thể đối chiếu Customers với account được hệ thống bên ngoài quản lý. |
Cấu trúc đích chính xác phụ thuộc vào bản cài đặt Bagisto thực tế. Bagisto core, Multi Vendor Marketplace, B2B Marketplace, B2B eCommerce và multi-tenant packages không dùng một schema Customers chung. Cần coi chúng là các vùng sở hữu dữ liệu riêng thay vì giả định có thể thay thế cho nhau.
Orders cần duy trì ngữ cảnh thương mại lịch sử
Orders trong Bagisto liên kết Customers hoặc guest identity, addresses, chi tiết mặt hàng, cấu hình Products được chọn, giá, discounts, Taxes, shipping, nhãn payment, statuses, invoices, shipments, refunds và transactions. Những bản ghi liên quan này giải thích điều gì đã xảy ra; riêng phần header của Orders là chưa đủ.
Lịch sử đơn hàng còn chứa snapshots tại thời điểm mua. Tên Products, giá, Taxes, addresses và options có thể phản ánh giao dịch khi đó dù Products hoặc Customers hiện tại đã thay đổi. Thay snapshots bằng dữ liệu catalog hiện tại sẽ làm sai lịch sử. Ngược lại, chỉ chuyển totals mà không có chi tiết mặt hàng và trạng thái sẽ làm công việc chăm sóc khách hàng và reporting thiếu tin cậy.
| Quan hệ trong Orders | Ý nghĩa lịch sử |
|---|---|
| Chi tiết mặt hàng | Danh tính Products, SKU, số lượng, giá, cấu hình đã chọn và snapshot mô tả. |
| Address | Billing và shipping tại thời điểm mua. |
| Invoice | Giá trị được ghi nhận/lập hóa đơn, có thể khác giai đoạn vòng đời của Orders. |
| Shipment | Bản ghi xử lý giao hàng và số lượng đã gửi. |
| Refund | Giá trị hoàn và phần mặt hàng/số tiền bị đảo ngược. |
| Transaction | Tham chiếu hệ thống payment và dữ liệu xác nhận trạng thái khi Cửa hàng nguồn có thông tin này. |
| Trạng thái Orders | Ý nghĩa vòng đời ở Cửa hàng nguồn, có thể cần một trạng thái tương ứng được quyết định rõ trên Cửa hàng đích. |
Phạm vi cần giữ mức chi tiết đủ cho chăm sóc Customers, account history, reporting và đối chiếu với hệ thống bên ngoài. Payment, shipping, Tax và notifications đang hoạt động thuộc cấu hình Cửa hàng đích; nhãn và giá trị lịch sử thuộc ngữ cảnh Orders đã di chuyển.
CMS, URLs, dữ liệu marketing và search có chủ thể sở hữu riêng
Bagisto có CMS Pages, URL rewrites, sitemaps, search terms, search synonyms, newsletter subscriptions, Reviews, cart rules và catalog rules. Không nên gộp chúng vào một nhóm “nội dung” chung vì mỗi loại phục vụ mục đích khác nhau.
CMS Pages sở hữu nội dung trang và danh tính URL. Metadata của Products/Categories thuộc bản ghi catalog tương ứng. URL rewrites duy trì quan hệ route. Search terms và synonyms ảnh hưởng đến khả năng tìm kiếm trong storefront. Reviews liên kết Customers với Products. Newsletter subscriptions thể hiện consent và audience. Cart rules và catalog rules mô tả điều kiện và hành động, không chỉ một giá trị discount.
| Dữ liệu nguồn | Cấu trúc Bagisto | Ranh giới cần duy trì |
|---|---|---|
| Trang thông tin | CMS Page | Nội dung, route, metadata và quan hệ điều hướng là các trách nhiệm riêng. |
| Metadata của Products hoặc Categories | Bản ghi catalog | Trường SEO gắn với đúng loại dữ liệu và locale. |
| URL cũ hoặc redirect | URL rewrite/redirect structure | Đường dẫn cũ và đích phải được giữ như một quan hệ rõ ràng. |
| Search synonym | Bản ghi search synonym | Cặp từ khóa không phải nội dung trang thông thường. |
| Reviews của Products | Quan hệ Products-Customers | Rating, tác giả, trạng thái và Products liên quan đều có ý nghĩa. |
| Promotion rule | Cart rule hoặc catalog rule | Điều kiện, hành động, thời gian, channels và nhóm Customers tạo thành một cấu trúc rule. |
Dữ liệu marketing đặc biệt dễ mất ý nghĩa khi bị rút gọn. Một mã giảm giá không còn conditions, thời gian, phạm vi Customers, usage history hoặc discount action không còn là cùng một promotion. Nếu không có cấu trúc rule tương ứng, nên giữ dữ liệu như lịch sử tham chiếu hoặc thiết kế lại dưới dạng cấu hình trên Nền tảng đích thay vì ép mapping trực tiếp.
Packages, APIs, cửa hàng Headless và custom tables mở rộng mô hình dữ liệu
Bagisto có thể được mở rộng bằng Laravel packages, các loại Products tùy chỉnh, modules, REST/GraphQL APIs, webhooks, code tích hợp và cửa hàng Headless. Dữ liệu của các thành phần này có thể không xuất hiện trong bảng Products, Customers hoặc Orders cốt lõi.
Package có thể tạo các loại bản ghi riêng, pivot relationships, configuration, statuses, permissions và external identifiers. Cửa hàng Headless có thể dùng dữ liệu cốt lõi của Bagisto nhưng lưu page composition hoặc chỉ mục tìm kiếm ở nơi khác. ERP, PIM, WMS, CRM, Marketplace connector hoặc mobile app có thể xem Bagisto chỉ là một thành phần trong hệ thống dữ liệu lớn hơn.
| Chủ thể sở hữu dữ liệu | Ví dụ | Ý nghĩa đối với di chuyển dữ liệu |
|---|---|---|
| Bagisto core | Products, Categories, Customers, Orders, attributes, channels, inventory sources | Mapping theo đúng semantics của loại dữ liệu và quan hệ có sẵn. |
| Package được cài | Marketplace sellers, B2B companies, booking resources, subscriptions, các loại Products tùy chỉnh | Rà soát schema package và giữ liên kết với bản ghi core. |
| Laravel module tùy chỉnh | các bảng, các trường dữ liệu, bản ghi quy trình hoặc event history riêng | Quyết định rõ đích hoặc cách archive cho từng quan hệ còn hoạt động. |
| Lớp hiển thị Headless | Page composition, chỉ mục tìm kiếm, nội dung chỉ có ở frontend, cached identifiers | Không giả định phần hiển thị storefront nằm trong Bagisto core. |
| Hệ thống bên ngoài | ERP item ID, CRM account ID, warehouse code, Marketplace listing ID | Giữ identifiers cần thiết để kết nối lại Cửa hàng đích với hệ thống quản lý chính. |
Câu hỏi quyết định là ai sở hữu dữ liệu. Một giá trị được lưu gần Products không có nghĩa giá trị đó thuộc Products. Giá trị đó có thể thuộc package, hệ thống bên ngoài hoặc lớp hiển thị. Phạm vi chỉ đầy đủ khi các quan hệ này đã được gọi tên và mọi bản ghi còn cần cho vận hành đều có đích rõ ràng.
Quyết định chuyển đổi dữ liệu phải dựa trên ý nghĩa kinh doanh
| Mô hình ở Cửa hàng nguồn | Câu hỏi cần trả lời trong Bagisto | Hệ quả nếu chọn sai cấu trúc |
|---|---|---|
| Options có SKU con và tồn kho | Đây có phải quan hệ configurable Products không? | Danh tính variants, inventory hoặc giá bị sai. |
| Specifications tái sử dụng cho cả nhóm Products | Có thuộc attributes và attribute family không? | Filtering và quản trị catalog tiếp tục thiếu nhất quán. |
| Các store theo khu vực | Đây là channels, locales, currencies hay các bản cài đặt độc lập? | Products và nội dung xuất hiện sai ngữ cảnh storefront. |
| Số lượng theo warehouse | Inventory source nào sở hữu từng số lượng? | Tổng tồn kho đúng nhưng khả năng bán theo vị trí sai. |
| Customers bán buôn hoặc company accounts | Ý nghĩa thực tế là nhóm Customers, B2B company, company user hay external account? | Giá, quyền truy cập và quan hệ account bị làm phẳng. |
| Products và Orders thuộc seller | Package Marketplace có sở hữu quan hệ seller không? | Vendor ownership, commission và payout context bị mất. |
| Các trường tùy chỉnh do package tạo | Loại bản ghi của package nào liên kết với bản ghi core nào? | Dữ liệu được sao chép nhưng quy trình sử dụng dữ liệu không còn. |
Một dự án chuyển sang Bagisto trở nên nhất quán khi Products, attributes, channels, inventory, Customers, Orders, nội dung, packages và external identifiers được chuyển như các cấu trúc có quan hệ. Mục tiêu không chỉ là dữ liệu xuất hiện, mà là duy trì ý nghĩa thương mại để Cửa hàng đích có thể tiếp tục vận hành với dữ liệu đó.
Kết luận
Chuyển sang Bagisto đòi hỏi diễn giải quan hệ trên nhiều lớp: catalog, storefront, inventory, Customers, Orders, nội dung, extensions và các tích hợp. Các loại Products xác định cấu trúc có thể bán. Attribute families quản lý thông tin Products. Channels kết nối catalog với localization và inventory. Các nhóm Customers cùng packages B2B/Marketplace có thể tạo những quan hệ account khác nhau. Orders phụ thuộc chi tiết mặt hàng, snapshots, invoices, shipments, refunds và transactions. Packages và hệ thống bên ngoài có thể sở hữu dữ liệu không thuộc Bagisto core.
Quyết định phạm vi tốt nhất là xác định chủ thể sở hữu từng giá trị thương mại quan trọng và giữ các liên kết giữa bản ghi. Nếu chỉ mapping theo tên trường, sự linh hoạt của Bagisto có thể che giấu việc mất ý nghĩa. Nếu mapping theo mục đích và quan hệ, Cửa hàng đích sẽ nhận được catalog và lịch sử thương mại vẫn dễ hiểu và sử dụng được.
Câu hỏi thường gặp
Configurable Products trong Bagisto khác options thông thường như thế nào?
Configurable Products liên kết một bản ghi Products cha với các variations có thể bán được tạo từ attributes đã chọn. Variations có thể có SKU, giá, số lượng, hình ảnh hoặc khả năng hiển thị riêng. Một option text không xác định một variation được quản lý độc lập thì không nên tự động biến thành cùng cấu trúc.
Vì sao attribute families quan trọng khi chuyển sang Bagisto?
Attribute families xác định attributes nào thuộc một nhóm Products. Cấu trúc này tránh việc mọi Products đều nhận một tập trường quá lớn và giúp phân biệt rõ thông số apparel, dữ liệu thiết bị, nội dung tải xuống, thông tin booking và các nhóm thông tin đặc thù khác.
Một store ở Cửa hàng nguồn có luôn tương ứng với một Bagisto channel không?
Một “store” nguồn không phải lúc nào cũng tương ứng với một Bagisto channel. Store đó có thể đại diện domain, language, currency, brand, region, catalog hoặc business unit độc lập. Cấu trúc Bagisto phù hợp có thể là một channel với nhiều locales, nhiều channels hoặc thậm chí nhiều bản cài đặt tùy quan hệ nào phải duy trì độc lập.
Tồn kho theo warehouse nên được thể hiện trong Bagisto như thế nào?
Khi vị trí có ý nghĩa, tồn kho cần giữ quan hệ với inventory source tương ứng. Gộp mọi số lượng thành một tổng Products duy nhất có thể làm mất warehouse, pickup, supplier hoặc ngữ cảnh xử lý đơn hàng dù tổng số đơn vị vẫn đúng.
Marketplace sellers và B2B companies có phải Customers thông thường trong Bagisto không?
Marketplace sellers và B2B companies không nhất thiết là Customers thông thường. Quan hệ seller và company có thể thuộc packages Marketplace hoặc B2B được cài thêm. Những cấu trúc này có thể bao gồm organization users, roles, catalogs, commissions, payouts, credit, quotations hoặc purchase Orders không phù hợp với Customers cốt lõi.
Dữ liệu của Bagisto package hoặc custom module nên được xử lý thế nào?
Cần xác định package/module, các bản ghi core được mở rộng và quy trình kinh doanh đang sử dụng dữ liệu đó. Quan hệ còn hoạt động cần một đích rõ ràng trên Cửa hàng đích và identifiers phải được giữ khi cần; dữ liệu lỗi thời có thể archive hoặc loại khỏi phạm vi thay vì giả định đó là trường có sẵn của Products hoặc Customers.