Những lỗi nghiêm trọng khi chuyển đổi sang BigCommerce thường không nằm ở việc thiếu bản ghi, mà ở việc các quan hệ giúp những bản ghi đó có ý nghĩa trên storefront hoặc trong vận hành bị mất. Variants và modifiers có thể trông giống nhau ở Nền tảng nguồn nhưng ảnh hưởng đến cách xử lý đơn hàng theo những cách khác nhau. Nhóm Customers và bảng giá đều có thể quyết định người mua nhìn thấy gì, nhưng chúng không phải một trường định giá duy nhất. Channels, sites, cây Categories, nội dung, địa điểm tồn kho và framework của storefront tiếp tục bổ sung những lớp quan hệ riêng.
Tám sai lầm dưới đây tập trung vào các tình huống khiến BigCommerce Store có vẻ đầy đủ dữ liệu nhưng vận hành không nhất quán về mặt thương mại. Mỗi phần phòng tránh xác định quan hệ phải tiếp tục đúng và điều kiện cụ thể dùng để chứng minh rủi ro đã được kiểm soát.
Sai lầm 1: Xem variants, modifiers và các trường của Products như cùng một mô hình lựa chọn
Vấn đề xảy ra
Options ở nguồn được đưa vào bất kỳ trường của BigCommerce nào có vẻ thuận tiện nhất. Child SKUs có inventory riêng bị chuyển thành modifiers, personalization lại trở thành variants, còn technical specifications bị biến thành lựa chọn mà người mua phải chọn.
BigCommerce variants là các tổ hợp từ giá trị của variant options và có thể mang dữ liệu thương mại riêng. Modifiers ghi nhận lựa chọn tùy chỉnh hoặc bổ sung cho mặt hàng nhưng không làm thay đổi variant được lấy từ tồn kho. các trường tùy chỉnh của Products và metafields phục vụ những mục đích mô tả hoặc vận hành khác.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo | Ý nghĩa của dấu hiệu |
|---|---|
| Tổ hợp size và color có stock riêng lại được tạo thành modifiers. | Lựa chọn có inventory đang bị tách khỏi variant identity. |
| Engraving, date, file upload hoặc warranty choices được tạo thành variants. | Personalization không có inventory đang bị biến thành SKUs giả. |
| Child SKUs ở nguồn bị mất vì Products cha được xem là đơn vị inventory duy nhất. | Xử lý đơn hàng và tồn kho sẽ sai ở cấp variant. |
| thông số Products chỉ còn xuất hiện trong descriptions hoặc shopper choices. | Structured attributes đang bị trộn với selling controls. |
Cách phòng tránh
Phân loại từng giá trị ở nguồn theo cách giá trị đó ảnh hưởng đến xử lý đơn hàng. Dùng variants cho những tổ hợp có thể bán và nhận diện độc lập; dùng modifiers cho tùy chỉnh theo từng lần mua nhưng không chọn một variant khác có tồn kho riêng; dùng các trường tùy chỉnh hoặc metafields cho dữ liệu mô tả hay vận hành.
Cần duy trì giá trị variant option, SKU, tồn kho, giá, trọng lượng, hình ảnh và external identifiers như một quan hệ thống nhất. Modifier selections phải đi cùng chi tiết mặt hàng trong Orders và không được tạo inventory cho các tổ hợp modifier.
Tình huống minh họa
Với quần may đo, số đo vòng eo và chiều dài ống quần nên trở thành variants khi từng tổ hợp được theo dõi tồn kho và xử lý đơn hàng riêng. Monogram text nên là modifier, còn hướng dẫn chăm sóc vải có thể được lưu như custom data của Products.
Điều kiện đạt
Mọi lựa chọn trong bộ mẫu đều dẫn đến đúng variant cần được xử lý trong đơn hàng, modifier selections vẫn được lưu trong chi tiết mặt hàng của Orders, còn các trường mô tả không tạo variants hoặc bản ghi tồn kho giả.
Sai lầm 2: Giữ Categories nhưng làm hỏng cây Categories và hành trình tìm Products
Vấn đề xảy ra
Categories ở nguồn được import thành một hierarchy phẳng hoặc một cây dùng chung mà không xem xét cây Categories, channel context, menus, faceted search, sorting hay storefront framework trên BigCommerce. Products vẫn thuộc Categories, nhưng khách hàng gặp nhánh bị thiếu, filters không liên quan hoặc storefront sử dụng sai cây Categories.
Một nhóm Categories ở nguồn cũng có thể đại diện cho brand, campaign, internal grouping hoặc SEO landing page chứ không phải một cấp catalog cần duy trì lâu dài.
Dấu hiệu cảnh báo sớm
- Một cây Categories được giả định là phù hợp cho mọi storefront hoặc channel.
- Quan hệ gán Products được rà soát mà không kiểm tra storefront đang dùng cây Categories nào.
- Giá trị brand, attribute và campaign đều được chuyển thành Categories.
- Dự án kỳ vọng navigation và faceted search tự hình thành từ các bản ghi Categories đã import.
Cách phòng tránh
Phân loại các nhóm ở nguồn theo mục đích. Xây dựng hoặc gán đúng cây Categories cho từng storefront context, duy trì quan hệ Products-Categories và tách riêng ý nghĩa của brands, filters, campaigns cùng navigation.
Cần xác định những giá trị nào phục vụ faceted search và Categories nào cần content, sorting, images hoặc redirects. Stencil, Catalyst và storefront Headless nên được xem là các cách triển khai sử dụng quan hệ catalog, không phải kết quả tự động có được sau khi import Categories.
Tình huống minh họa
Với doanh nghiệp có storefront retail và wholesale, có thể dùng các cây Categories khác nhau theo channel khi hành trình người mua khác nhau, giữ chung Products identity khi phù hợp và duy trì attributes của Products hoặc custom data dùng cho filters thay vì nhân bản chúng thành Categories.
Điều kiện đạt
Mỗi storefront sử dụng đúng cây Categories dự kiến, Products nằm trong đúng branches, navigation dẫn đến các branches đó và filters dựa trên dữ liệu nhất quán thay vì việc nhân bản Categories phát sinh ngoài ý muốn.
Sai lầm 3: Tách nhóm Customers khỏi bảng giá tạo nên ý nghĩa thương mại của nhóm
Vấn đề xảy ra
Nhóm Customers được chuyển như các nhãn, còn bảng giá, các bản ghi giá ở cấp variant, quyền truy cập Categories hoặc channel assignments được xử lý riêng. Customers nằm trong đúng group nhưng vẫn thấy giá catalog, sai currency hoặc assortment không đúng quyền.
BigCommerce price lists có thể override pricing ở cấp variant và có thể được gán qua nhóm Customers, channels hoặc tổ hợp nhóm Customers với channel. Bảng giá tồn tại mà thiếu assignment chưa tạo thành một mô hình pricing hoàn chỉnh.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo | Ý nghĩa của dấu hiệu |
|---|---|
| di chuyển dữ liệu của group được xem là xong khi Customers hiển thị đúng tên group. | Ý nghĩa thương mại của group chưa được duy trì. |
| Prices chỉ được mapping ở cấp Products dù variants có giá khác nhau. | Price-list coverage sẽ sai với một số mặt hàng có thể bán cụ thể. |
| Price-list assignments không có channel context. | Một mức giá hợp lệ có thể xuất hiện trên sai storefront hoặc không xuất hiện nơi cần thiết. |
| Bulk pricing và price-list overrides được kết hợp mà không xác định precedence. | Các cơ chế pricing cạnh tranh có thể tạo kết quả không nhất quán. |
Cách phòng tránh
Mô hình hóa group, quyền truy cập Categories, bảng giá, bản ghi giá ở cấp variant, currency, channel và assignment như các cấu trúc có liên hệ. Cần duy trì chính xác quan hệ quyết định Customers đã đăng nhập nào nhận mức giá của variant nào trên storefront nào.
Tách mức giá đã ghi trong lịch sử đơn hàng khỏi các bản ghi trong bảng giá đang hoạt động. Nếu hệ thống ERP hoặc hợp đồng bên ngoài tiếp tục quản lý pricing, cần giữ các identifiers mà hệ thống đó sử dụng.
Tình huống minh họa
Với nhóm VIP mua hàng trên storefront theo khu vực, cần giữ quan hệ nhóm Customers, quyền truy cập Categories, bảng giá, các bản ghi giá ở cấp variant, currency và assignment liên kết group với channel tương ứng.
Điều kiện đạt
Customers đại diện sau khi đăng nhập thấy đúng assortment và giá của variants trên đúng channel, trong khi Customers ngoài nhóm nhận đúng fallback pricing.
Sai lầm 4: Xem channels, sites và storefronts như các nhãn hiển thị
Vấn đề xảy ra
Products, Categories, Customers, prices, currencies, menus và content được di chuyển mà không duy trì quan hệ channel và site quyết định chúng xuất hiện ở đâu. Storefront mặc định có thể đúng, nhưng các brand, khu vực, marketplace hoặc trải nghiệm Headless khác lại nhận sai catalog và configuration.
Trên BigCommerce, channel đại diện cho một bối cảnh bán hàng, còn site đại diện cho website do merchant quản lý và được gắn với storefront channel. Vì vậy, channel-specific assignments và settings ảnh hưởng nhiều hơn một display label.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo | Ý nghĩa của dấu hiệu |
|---|---|
| Bản ghi tự rơi vào channel chính vì không có channel ID. | Quan hệ thuộc từng channel chưa được giữ đúng trong các bản ghi đã di chuyển. |
| Products và price-list assignments được rà soát chung toàn hệ thống thay vì theo storefront. | Khác biệt về assortment và pricing riêng từng storefront đang bị làm phẳng. |
| Domains, sites, menus, currencies và cây Categories được ghi nhận tách rời nhau. | Quan hệ storefront hoàn chỉnh chưa được quản lý như một hệ thống thống nhất. |
| Apps và các tích hợp giả định mọi tương tác Orders hoặc Products đều thuộc default channel. | Hệ thống phía sau sẽ phân loại sai nguồn và bối cảnh. |
Cách phòng tránh
Xác định mô hình channel trước khi chốt mapping. Cần liệt kê từng storefront, marketplace, POS, marketing hoặc custom channel; site và domain gắn với từng storefront; cùng Products, cây Categories, pricing, currency, menu, Orders và app context thuộc về bối cảnh đó.
Giữ channel IDs và source channel references trong mappings của các tích hợp. Không nên dùng default channel như một fallback không được giải thích.
Tình huống minh họa
Với hai storefronts cho hai brands và một Amazon channel, có thể giữ một bản ghi Products catalog dùng chung khi phù hợp, nhưng phải gán Products và bảng giá cho đúng storefront channels, dùng đúng cây Categories và site cho từng brand, đồng thời giữ riêng nguồn marketplace của Orders.
Điều kiện đạt
Products, prices, menus, cây Categories, Orders và các tích hợp đều resolve về đúng channel và site. Không có storefront phụ nào vô tình phụ thuộc vào hành vi mặc định của channel chính.
Sai lầm 5: Import inventory mà không giữ bối cảnh location và channel
Vấn đề xảy ra
Một số lượng tồn kho được sao chép vào Products hoặc variant dù hệ thống nguồn theo dõi nhiều warehouses, retail stores, pickup points, suppliers hoặc channel allocations. Tổng số trông hợp lý, nhưng khả năng nhận hàng tại điểm, xử lý đơn hàng và đồng bộ với hệ thống bên ngoài lại tham chiếu sai location hoặc sai mặt hàng có thể bán.
Vấn đề nghiêm trọng hơn khi nguồn có stock ở cấp variant nhưng mapping đích dùng Products cha, hoặc khi WMS tiếp tục là hệ thống quản lý inventory chính sau di chuyển dữ liệu.
Dấu hiệu cảnh báo sớm
- Inventory files có SKU và quantity nhưng không có location identifier.
- Quantity ở cấp Products cha được dùng cho Products có variants thực sự.
- BOPIS hoặc pickup locations không có trong bảng đối chiếu locations.
- External warehouse IDs bị loại bỏ sau khi import opening quantities.
Cách phòng tránh
Liên kết dữ liệu tồn kho với đúng variant của Products và BigCommerce location quản lý số lượng đó. Cần giữ location identifiers, variant SKUs, khóa tồn kho của hệ thống bên ngoài và mọi quan hệ channel hoặc pickup mà quy trình tiếp tục sử dụng.
Tách lượng tồn kho hiện có để bán khỏi lịch sử biến động, lượng đã được giữ chỗ, hàng hư hỏng và lượng hàng phía nhà cung cấp còn có thể đáp ứng và những trạng thái khác không thuộc opening quantity.
Tình huống minh họa
Với retailer có một central warehouse và ba pickup stores, cần mapping từng source location sang BigCommerce location tương ứng, giữ quantities ở cấp variant và warehouse keys, đồng thời tách rules về channel hoặc pickup availability khỏi raw quantity.
Điều kiện đạt
Các variants mẫu hiển thị đúng số lượng ở từng location, dịch vụ nhận hàng tại điểm hoặc xử lý đơn hàng xác định đúng hệ thống chịu trách nhiệm về tồn kho và hệ thống quản lý tồn kho tiếp tục cập nhật đúng các bản ghi variant-location mà không tạo bản ghi trùng lặp.
Sai lầm 6: Xem redirects như một lần import kỹ thuật ở cuối dự án
Vấn đề xảy ra
Redirects chỉ được tạo sau khi Products, Categories, page và storefront routes đã chốt. URLs cũ được mapping máy móc đến target path gần nhất mà không giữ đúng mục đích của người dùng, channel, site, locale hoặc quyền sở hữu content.
BigCommerce có thể quản lý redirects và site routes, nhưng một redirect file không giải quyết được content bị thiếu, cây Categories sai, khác biệt của storefront framework hoặc destination riêng theo channel.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo | Ý nghĩa của dấu hiệu |
|---|---|
| Kế hoạch redirects có URLs của Products nhưng bỏ Categories, pages, Blog Posts, filtered routes và campaign content. | Danh sách redirects chưa bao phủ đầy đủ những routes đang nhận traffic. |
| Một destination được dùng cho nhiều storefronts dù mỗi site có cấu trúc routes khác nhau. | Các hành trình riêng theo channel đang bị gộp. |
| Redirects trỏ tới pages chưa publish hoặc không có trên storefront đang hoạt động. | Mapping tồn tại về kỹ thuật nhưng khách hàng không sử dụng được. |
| Legacy query parameters và routes do app tạo ra bị bỏ qua. | Những routes quan trọng ngoài canonical path hoặc do các tích hợp tạo có thể lỗi mà khó nhận biết. |
Cách phòng tránh
Lập danh sách các đường dẫn và gắn từng đường dẫn với chủ thể quản lý trang đích. Mỗi source URL quan trọng cần được map tới Products, Categories, page, Blog Post, site route, ứng dụng storefront, nội dung thay thế hoặc một quyết định chủ động ngừng sử dụng.
Ưu tiên revenue, organic traffic, backlinks, bookmarks của khách hàng và campaigns đang hoạt động. Khi cùng một source pattern cần destinations khác nhau, phải giữ rõ channel và site context.
Tình huống minh họa
Với doanh nghiệp dùng nhiều storefronts, cần mapping riêng Products và URLs của Categories quan trọng nhất cho từng website theo brand, đưa campaign pages đã ngừng sử dụng tới nội dung thay thế phù hợp và giữ các đường dẫn của ứng dụng Headless tại nơi storefront sở hữu chúng bên ngoài catalog chính.
Điều kiện đạt
Priority URLs dẫn đến content hữu ích trên đúng site và channel, không redirect nào trỏ đến destination không khả dụng và mọi path bị bỏ qua đều có quyết định ngừng sử dụng rõ ràng.
Sai lầm 7: Sao chép các trường tùy chỉnh và metafields mà không xác định ứng dụng chịu trách nhiệm
Vấn đề xảy ra
các trường tùy chỉnh, app data, các flags phục vụ các tích hợp, SEO values và external identifiers ở nguồn đều được mapping vào các trường tùy chỉnh của Products hoặc metafields. Các giá trị được đưa sang nhưng không xác định rõ kiểu dữ liệu, quyền truy cập, namespace, thành phần sử dụng hoặc resource cha.
BigCommerce hỗ trợ metafields trên nhiều resources và các trường tùy chỉnh của Products cho thông tin storefront, nhưng các cấu trúc này không tự tái tạo app, theme, các tích hợp hoặc quy trình từng sử dụng dữ liệu ở nguồn.
Dấu hiệu cảnh báo sớm
- Cấu trúc đích được chọn dựa trên nhãn trường ở nguồn thay vì thành phần thực sự sử dụng dữ liệu.
- Giá trị ở cấp variant lại được gắn vào Products cha.
- các trường do app sở hữu được tạo lại dưới namespaces không liên quan.
- Source IDs từng tham chiếu Products, Customers, media hoặc Orders được sao chép nguyên xi.
Cách phòng tránh
Phân loại custom data theo chủ thể quản lý và công dụng. Dùng các trường tùy chỉnh của Products cho thông tin Products phù hợp để hiển thị trên storefront, resource metafields cho dữ liệu vận hành có kiểu xác định hoặc dữ liệu do ứng dụng sử dụng, và tiếp tục để hệ thống bên ngoài quản lý những bản ghi thuộc trách nhiệm của hệ thống đó.
Các references phải được nối lại với destination IDs tương ứng. Đồng thời cần duy trì namespaces và permissions, và ghi rõ theme, app, API hoặc các tích hợp nào sử dụng từng trường.
Tình huống minh họa
Có thể lưu material specification công khai dưới dạng trường tùy chỉnh của Products khi storefront cần hiển thị. Warehouse code ở cấp variant có thể được lưu như variant metafield, còn trạng thái đăng ký định kỳ nên tiếp tục do ứng dụng quản lý dịch vụ đăng ký định kỳ chịu trách nhiệm.
Điều kiện đạt
Custom data nằm trên đúng resource, được đúng storefront hoặc system sử dụng, không có namespaces bị bỏ rơi, không chuyển giá trị từ resource con lên resource cha sai mục đích và không sao chép source IDs chưa được nối lại.
Sai lầm 8: Xem sự tồn tại của Customers và Orders là đủ để duy trì vận hành
Vấn đề xảy ra
Số lượng Customers và Orders khớp, nhưng identity, addresses, group assignment, consent, variants trong chi tiết mặt hàng trong Orders, discounts, taxes, shipping, refunds, consignments, shipments, statuses và external references lại thiếu. Sau đó, nhãn thanh toán và vận chuyển trong lịch sử bị nhầm với cấu hình checkout và xử lý đơn hàng đang hoạt động.
Lỗi này làm dịch vụ khách hàng và finance khó sử dụng dữ liệu ngay cả khi Store vẫn có thể nhận Orders mới bình thường.
Dấu hiệu cảnh báo sớm
- danh tính Customers chỉ được đối chiếu bằng email.
- Group assignment được rà soát nhưng không kiểm tra pricing và quyền truy cập Categories.
- Orders chỉ được chọn mẫu theo mã đơn hàng và tổng tiền.
- Bộ mẫu thiếu Orders có nhiều địa chỉ, hoàn tiền, xử lý đơn hàng một phần hoặc nguồn channel cụ thể.
Cách phòng tránh
Duy trì danh tính Customers, addresses, attributes, consent, group và external IDs theo đúng mục đích kinh doanh. Lịch sử đơn hàng cần giữ chi tiết mặt hàng trong Orders, variants, prices, adjustments, taxes, địa chỉ giao hàng, consignments, shipments, refunds, statuses, notes, channel origin và external references ở mức mà dịch vụ khách hàng và finance cần dùng.
Dữ liệu lịch sử phải được tách khỏi cấu hình thanh toán, checkout, vận chuyển, thuế và xử lý đơn hàng đang hoạt động.
Tình huống minh họa
Với Orders theo khu vực mới chỉ được xử lý một phần, cần giữ Customers và group, variants đã mua, channel, địa chỉ giao hàng, consignments, thông tin theo dõi lô hàng, discount, tax, chi tiết hoàn tiền và ERP ID của Orders. Cấu hình checkout và vận chuyển cho các đơn hàng mới trong khu vực phải được thiết lập riêng.
Điều kiện đạt
Customers vẫn có thể được nhận diện và phân loại đúng về mặt thương mại, lịch sử đơn hàng tiếp tục đủ rõ cho dịch vụ khách hàng và finance, còn hoạt động hiện tại không dựa vào imported labels như thể chúng là configuration.
Ưu tiên phòng tránh xuyên suốt tám sai lầm
| Ưu tiên | Kiểm soát cần có |
|---|---|
| Quyền sở hữu lựa chọn Products | Tách variants, modifiers, các trường tùy chỉnh, metafields và app data theo đúng cách chúng hoạt động. |
| Bối cảnh storefront | Duy trì quan hệ channel, site, cây Categories, menu, route và pricing. |
| Bối cảnh thương mại | Kết nối nhóm Customers với quyền truy cập Categories, bảng giá, giá của variants và channels. |
| Danh tính vận hành | Giữ ổn định identifiers của variants, locations, Customers, Orders, channels và hệ thống bên ngoài. |
| Tách dữ liệu lịch sử khỏi cấu hình hiện tại | Duy trì thông tin Orders cần thiết mà không dùng chúng như cấu hình checkout hoặc xử lý đơn hàng đang hoạt động. |
Những kiểm soát này cần được rà soát cùng nhau vì một lỗi trên BigCommerce thường ảnh hưởng nhiều quan hệ. Sai variant có thể đồng thời làm pricing, inventory, lựa chọn trên storefront, dữ liệu Orders và external identifiers sai theo. Hồ sơ phòng tránh cần nêu rõ người hoặc hệ thống chịu trách nhiệm và kết quả kiểm tra cho từng phần bị ảnh hưởng.
Kết luận
Sai lầm khi chuyển đổi sang BigCommerce xuất hiện khi các bản ghi có liên hệ được import như những phần độc lập. Variants, modifiers, cây Categories, nhóm Customers, bảng giá, channels, sites, inventory locations, redirects, custom data, Customers và Orders đều mang bối cảnh cần tiếp tục được kết nối đúng.
Cách phòng tránh hiệu quả nhất là xác định những quan hệ này trước khi mapping ở quy mô lớn. Khi mỗi bản ghi có đúng chủ thể quản lý, channel, bối cảnh thương mại và định danh bên ngoài và điều kiện đạt, Store sau di chuyển dữ liệu có thể vận hành nhất quán giữa các storefronts và hệ thống.
Câu hỏi thường gặp
Variant và modifier trên BigCommerce khác nhau như thế nào?
Variant đại diện cho tổ hợp có thể bán và có thể mang SKU, price, inventory, images cùng dữ liệu thương mại khác. Modifier thay đổi hoặc tùy chỉnh mặt hàng được xử lý trong đơn hàng nhưng không chọn một variant khác đang được theo dõi inventory.
Vì sao Categories đã di chuyển vẫn có thể hoạt động sai trên storefront BigCommerce?
Các bản ghi Categories còn phải thuộc đúng cây Categories và đúng storefront context. Navigation, faceted search, sorting, content và channel assignment là những quan hệ riêng cần được xác thực.
Nhóm Customers có tự tái tạo group pricing không?
Nhóm Customers không tự tái tạo group pricing. Pricing có thể còn phụ thuộc vào bảng giá, các bản ghi giá ở cấp variant, quyền truy cập Categories, currency, channel và price-list assignments. Chỉ có group label là chưa đủ.
Multi-Storefront ảnh hưởng đến phạm vi di chuyển dữ liệu như thế nào?
Products, cây Categories, bảng giá, currencies, menus, sites, routes, Orders và apps đều có thể mang ý nghĩa riêng theo channel. Mô hình di chuyển dữ liệu cần giữ các assignments này thay vì đưa mọi thứ về storefront đầu tiên theo mặc định.
Mọi trường tùy chỉnh ở nguồn có nên trở thành trường tùy chỉnh của BigCommerce của Products không?
Không phải mọi giá trị đều thuộc các trường tùy chỉnh của Products. Một số phù hợp với resource metafields, variants, apps, hệ thống bên ngoài hoặc phần triển khai storefront. Cấu trúc đích phải được chọn theo chủ thể quản lý, thành phần sử dụng, phạm vi hiển thị và resource cha của trường.
Orders đã import có cấu hình checkout và xử lý đơn hàng trên BigCommerce không?
Orders đã import chỉ duy trì dữ liệu giao dịch trong quá khứ. Checkout, thanh toán, vận chuyển, thuế, location và xử lý đơn hàng hiện tại cần được cấu hình riêng trên BigCommerce, đồng thời phải xác định rõ người hoặc hệ thống chịu trách nhiệm cho các tích hợp liên quan.