Chuyển đổi sang Adobe Commerce thường gặp vấn đề nghiêm trọng nhất khi bản ghi được di chuyển nhưng tách khỏi những quan hệ doanh nghiệp quyết định ai được mua, người mua nhìn thấy gì, mức giá nào được áp dụng, inventory được xử lý từ đâu và content bắt đầu có hiệu lực khi nào. Products có thể tồn tại trong giao diện quản trị nhưng vẫn sai về mặt thương mại nếu bị gán nhầm website, thiếu associated Simple Products, không nằm trong shared catalog cần thiết hoặc không còn quan hệ source và stock có thể sử dụng.
Vì vậy, những sai lầm gây ảnh hưởng lớn nhất không chỉ là thiếu bản ghi. Đó là các quan hệ bị đứt nhưng vẫn tạo cảm giác dữ liệu đã đầy đủ khi chỉ rà soát bề mặt. Để phòng tránh, mỗi quy tắc doanh nghiệp cần có chủ sở hữu rõ trên Adobe Commerce, một tình huống đại diện và điều kiện đạt cụ thể.
Sai lầm 1: Chuyển company accounts thành các bản ghi Customers rời rạc
Vấn đề xảy ra
B2B company accounts trong Adobe Commerce có thể chứa company administrators, teams, users, roles, permissions, addresses, điều kiện payment và các quan hệ mua hàng. Nếu chỉ nhập từng bản ghi Customers, di chuyển dữ liệu có thể giữ thông tin liên hệ nhưng làm mất tổ chức đứng phía trên để quản lý các người mua đó.
Cửa hàng có thể hiển thị đủ email dự kiến nhưng company administrators không còn quản lý được users, assistant buyers nhận quyền quá rộng và Orders không còn gắn với đúng business account.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo sớm | Điều dấu hiệu này cho thấy |
|---|---|
| Company, division, team và user được export thành một danh sách Customers duy nhất. | Hệ thống phân cấp B2B đang bị làm phẳng thành các tài khoản cá nhân không có quan hệ. |
| Administrator và buyer roles chỉ được lưu dưới dạng nhãn văn bản tự do. | Permissions và người sở hữu quyền phê duyệt không thể được tái lập ổn định. |
| Nhiều người mua dùng chung company pricing hoặc addresses nhưng không có company identifier bền vững. | Ngữ cảnh thương mại dùng chung sẽ bị phân mảnh giữa các Customers. |
| Nguồn dùng approval, account credit hoặc quy tắc payment bị giới hạn ngoài bản ghi Customers. | Một chức năng B2B quan trọng không có nơi tiếp nhận rõ trên đích. |
Cách phòng tránh
Xem company là cấu trúc doanh nghiệp cấp cha. Giữ company identifier, company administrator, subordinate users, teams, role assignments, addresses, quan hệ với nhóm Customers và external account key mà CRM hoặc ERP sử dụng. Không suy đoán company membership chỉ dựa vào email domain hoặc địa chỉ giống nhau.
Tình huống minh họa
Chọn một company có administrator, senior buyer và restricted buyer làm mẫu đại diện. Chuyển riêng company membership và role của từng user, đồng thời giữ shared account cùng external company identifier.
Điều kiện đạt
Company đại diện chỉ xuất hiện một lần, chứa đúng users và teams, mỗi role có đúng permissions dự kiến, đồng thời vẫn liên kết với đúng nhóm Customers, addresses và external account key.
Sai lầm 2: Gán shared catalogs nhưng làm mất pricing riêng theo company
Vấn đề xảy ra
Shared catalogs có thể kiểm soát Products được phép mua và custom pricing cho company accounts. Nếu nhập Products và companies nhưng làm mất quan hệ shared catalog, Products bị giới hạn có thể bị hiển thị công khai, Products theo hợp đồng có thể biến mất khỏi tài khoản được phép mua hoặc negotiated prices có thể bị thay bằng mức giá catalog chung.
Lỗi này dễ bị bỏ qua vì catalog chính vẫn có thể trông đầy đủ trong giao diện quản trị trong khi khả năng hiển thị trên storefront thay đổi theo từng company.
Dấu hiệu cảnh báo sớm
- Cùng một SKU có mức giá khác nhau theo company hoặc nhóm Customers.
- Products riêng tư xuất hiện trong file export Products chung.
- Hợp đồng hoặc bản ghi ERP xác định mức giá không nằm trực tiếp trên Products nguồn.
- Company assignment và catalog assignment được quản lý trong các hệ thống nguồn khác nhau.
Cách phòng tránh
Tạo quan hệ rõ giữa company, shared catalog, lựa chọn Products, custom price, phạm vi website và nhóm Customers. Tách public catalog khỏi catalogs riêng cho company và giữ external contract identifier giải thích nguồn của mức giá khi có.
Tình huống minh họa
Dùng một SKU công khai, một SKU bị giới hạn và một SKU có giá theo hợp đồng. Kiểm tra cách từng SKU xuất hiện với khách chưa đăng nhập, Customers thông thường và hai companies được gán shared catalogs khác nhau.
Điều kiện đạt
Mỗi người mua đại diện chỉ nhìn thấy đúng Products và prices dự kiến, còn users ngoài company được gán không thể truy cập Products bị giới hạn hoặc negotiated values qua Categories, search, direct URLs, cart hay checkout.
Sai lầm 3: Tạo lại người mua nhưng làm mất quotes, purchase orders và quan hệ phê duyệt
Vấn đề xảy ra
Hoạt động mua hàng B2B trên Adobe Commerce có thể bao gồm negotiable quotes, purchase orders, approval rules, requisition lists và quyền truy cập theo role. Các dữ liệu này không phải Orders thông thường hay wish lists. Nếu bị làm phẳng thành ghi chú chung, chúng sẽ mất status, owner, approval path, line history và quan hệ với company account.
Người mua có thể còn lịch sử đơn hàng nhưng mất open quote, Purchase Orders đang chờ xử lý hoặc requisition list dùng cho mua hàng lặp lại.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo sớm | Điều dấu hiệu này cho thấy |
|---|---|
| Quotes và purchase orders được export cùng Orders nhưng dùng identifiers hoặc statuses khác. | Các quy trình mua hàng riêng đang bị gộp vào lịch sử đơn hàng đã hoàn tất. |
| Approval limits chỉ tồn tại trong policy documents hoặc hệ thống procurement bên ngoài. | Quy tắc kiểm soát nằm ngoài tập dữ liệu đang được di chuyển. |
| Requisition lists chứa các nhóm SKU mua lặp lại nhưng bị xem như wish lists. | Nhu cầu mua hàng vận hành đang bị hiểu sai thành sở thích merchandising. |
| Quote comments, revisions, expiration hoặc negotiated discounts không có nơi tiếp nhận dự kiến. | Lịch sử thương lượng thương mại sẽ không đầy đủ. |
Cách phòng tránh
Phân loại riêng từng B2B workflow. Giữ company, người tạo, người phê duyệt, status, các dòng hàng, quantities, negotiated adjustments, comments, dates và external references khi Nền tảng đích cần duy trì các quan hệ đó. Dữ liệu lịch sử không thể tiếp tục ở trạng thái đang hoạt động vẫn cần đủ ngữ cảnh để nhân sự và người mua hiểu trạng thái trước đây.
Tình huống minh họa
Chọn một open negotiable quote, một bản ghi Purchase Orders đã được duyệt, một bản ghi Purchase Orders đang chờ phê duyệt và một requisition list. Xác định nơi tiếp nhận trên đích và phần lịch sử cần giữ cho từng loại dữ liệu.
Điều kiện đạt
Nền tảng đích phân biệt quotes, purchase orders, approval relationships, requisition lists và Orders đã hoàn tất; mỗi bản ghi đại diện vẫn gắn với đúng company và user, có status cùng line history có thể hiểu được.
Sai lầm 4: Gộp phạm vi Adobe Commerce giữa websites, stores và store views
Vấn đề xảy ra
Adobe Commerce dùng hệ thống phân cấp websites, stores và store views. Phạm vi này có thể ảnh hưởng phân bổ Products, root Categories, nội dung bản địa hóa, URLs, cấu hình, currencies và ngữ cảnh thương mại B2B. Nếu nhập mọi dữ liệu ở phạm vi toàn cục, giá trị theo khu vực hoặc ngôn ngữ có thể bị ghi đè, còn Products hoặc content có thể xuất hiện ở sai storefront.
Default store view có thể trông đúng trong khi một ngôn ngữ, thương hiệu hoặc khu vực khác lại hiển thị fallback text, thiếu Products hoặc dùng sai routes.
Dấu hiệu cảnh báo sớm
- Products hoặc Categories khác nhau theo website hay thương hiệu.
- Names, descriptions, metadata và URL keys thay đổi theo store view.
- Mỗi store có root Categories hoặc menu khác nhau.
- Customers, shared catalogs, currencies hoặc content được ràng buộc với websites cụ thể.
Cách phòng tránh
Xác định quan hệ giữa hệ thống phân cấp của Cửa hàng nguồn và website, store, store view của Adobe Commerce trước khi gán giá trị cho từng đối tượng dữ liệu. Tách global attributes khỏi prices theo website và content theo store view. Giữ source scope codes khi các tích hợp hoặc quy trình import tiếp tục phụ thuộc vào chúng.
Tình huống minh họa
Dùng một bản ghi Configurable Products và một CMS Page có nội dung, URL keys và khả năng hiển thị khác nhau giữa hai store views và hai websites. Ghi rõ giá trị nào là global và giá trị nào thuộc từng phạm vi.
Điều kiện đạt
Mỗi website, store và store view đại diện hiển thị đúng phân bổ Products, root Categories, content bản địa hóa, URLs và ngữ cảnh thương mại mà không làm lộ giá trị thuộc phạm vi khác.
Sai lầm 5: Làm phẳng các loại Products phức tạp thành Products thông thường
Vấn đề xảy ra
Adobe Commerce hỗ trợ Simple, Configurable, Grouped, Virtual, Bundle, Downloadable và Gift Card Products. Các loại này có quan hệ cha-con, inventory, price, weight, file và cart khác nhau. Làm phẳng tất cả thành Products thông thường có thể tạo SKUs trùng, làm mất tổ hợp lựa chọn, phá cấu trúc bundle hoặc tách downloadable files khỏi Products tương ứng.
Products có thể trông đầy đủ nhưng không còn hoạt động như offer mà Customers từng mua.
Dấu hiệu cảnh báo sớm
- Parent và child SKUs không được nhận diện riêng.
- Bundle components hoặc Grouped Products chỉ được lưu thành văn bản trong descriptions.
- Download links và access limits được quản lý ngoài file export Products.
- Custom options bị trộn với configurable attributes.
Cách phòng tránh
Phân loại loại Products trước khi xác định trường đích. Giữ configurable parent-child associations, variation attributes, bundle options, grouped links, downloadable files, ý nghĩa không cần shipping của Virtual Products và cách các quan hệ này xuất hiện trong dòng hàng của Orders. Không tạo variants từ descriptive attributes nếu chúng không xác định đơn vị có thể bán độc lập.
Tình huống minh họa
Dùng một bản ghi Configurable Products có child inventory khác nhau, một bản ghi Bundle Products dùng dynamic pricing, một bản ghi Grouped Products và một bản ghi Downloadable Products. Giữ riêng cấu trúc thành phần và ý nghĩa xử lý đơn hàng của từng loại.
Điều kiện đạt
Mỗi bản ghi Products đại diện giữ đúng cấu trúc parent-child hoặc thành phần, selectable values, SKU identity, nguồn price, cách inventory hoạt động, media và ý nghĩa trong dòng hàng của Orders.
Sai lầm 6: Nhập campaign content nhưng làm mất timeline của Content Staging
Vấn đề xảy ra
Adobe Commerce Content Staging có thể lên lịch cập nhật cho Products, Categories, catalog và cart price rules, cũng như CMS Pages thông qua campaigns. Nếu chỉ nhập giá trị đang hiển thị, di chuyển dữ liệu có thể làm mất campaigns trong tương lai, baseline content, campaign grouping, khoảng thời gian hoạt động và cơ chế tự trở về baseline sau thời điểm kết thúc.
Một promotion tương lai có thể không bao giờ xuất hiện, hoặc campaign content có thể tồn tại vĩnh viễn vì timeline bị thu gọn thành các trường tĩnh.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo sớm | Điều dấu hiệu này cho thấy |
|---|---|
| Nguồn có thay đổi theo lịch cho Products, prices, Categories, rules hoặc CMS. | Chỉ lấy giá trị hiện tại không thể hiện đầy đủ kế hoạch campaign. |
| Đội marketing dựa vào staging calendar hoặc campaign names. | Thời điểm và việc kích hoạt đồng bộ là một phần của ý nghĩa nghiệp vụ. |
| Nhiều đối tượng dữ liệu thay đổi cùng một thời điểm phát hành. | Nhập từng bản ghi riêng không thể giữ quan hệ campaign. |
| Content đang hoạt động khác baseline version được lưu. | di chuyển dữ liệu có thể lấy nhầm trạng thái theo thời gian. |
Cách phòng tránh
Lập danh sách baseline values, scheduled updates, campaign membership, thời gian bắt đầu và kết thúc, giả định về time zone và store views chịu ảnh hưởng. Xác định campaigns nào còn giá trị và campaigns nào cần được xây dựng lại thành staged records hiện hành trên Adobe Commerce thay vì nhập như content tĩnh.
Tình huống minh họa
Dùng một campaign đồng thời thay đổi price của Products, content của Categories và CMS landing page. Giữ baseline values và khoảng thời gian campaign như hai trạng thái riêng.
Điều kiện đạt
Campaign đại diện có đúng các đối tượng dữ liệu, baseline content, schedule, store-view context và hành vi trở về trạng thái sau campaign; không có cập nhật tương lai nào bị âm thầm biến thành live data vĩnh viễn.
Sai lầm 7: Sao chép quantities nhưng không tái lập quan hệ sources, stocks và sales channels
Vấn đề xảy ra
Inventory trên Adobe Commerce tách physical sources khỏi stocks tổng hợp các sources cho sales channels. Một quantity không kèm source, stock, website, status và ngữ cảnh salable có thể đưa inventory vào sai warehouse hoặc khiến Products không thể bán dù quantity vẫn dương.
Cửa hàng dùng nhiều sources đặc biệt dễ gặp lỗi khi tất cả locations bị cộng dồn vào Default Source.
Dấu hiệu cảnh báo sớm
- Quantities theo warehouse, store, drop-shipper hoặc pickup location tồn tại riêng.
- Nguồn dùng allocation, reservation hoặc trạng thái có thể bán theo channel.
- Products sau import mặc định về một source dù nhiều locations cùng xử lý Orders.
- Child Products của Configurable Products có phạm vi locations khác nhau.
Cách phòng tránh
Giữ source identity, source code, source quantity, stock assignment, quan hệ website, status và external warehouse key. Tách quantity thực tế tại kho khỏi quantity có thể bán qua một sales channel cụ thể. Xác định hệ thống nào tiếp tục là hệ thống quản lý chính sau di chuyển dữ liệu.
Tình huống minh họa
Dùng một SKU có hàng tại hai warehouses và một Configurable Products có child Products được phục vụ từ các sources khác nhau. Gắn từng source với stock phục vụ website dự kiến.
Điều kiện đạt
Products đại diện hiển thị đúng source quantities, stock và website assignments, salable availability cùng quyền sở hữu xử lý đơn hàng, không gộp các locations khác nhau thành một tổng số lượng không được giải thích rõ.
Sai lầm 8: Xem URL rewrites và content theo phạm vi như các slugs đơn giản
Vấn đề xảy ra
Adobe Commerce có thể duy trì URL rewrites cho Products, Categories và CMS Pages. Routes có thể khác theo website hoặc store view, còn content có thể chứa internal links, media paths, Page Builder structures hoặc campaign references. Chỉ sao chép slug hiện tại có thể làm mất redirect history và phá các hành trình truy cập có giá trị cao.
Dấu hiệu cảnh báo sớm
- Nguồn có nhiều URLs trước đây cho cùng một loại dữ liệu.
- URL keys của Products hoặc Categories khác nhau theo store view.
- CMS content chứa source URLs hoặc media paths được ghi trực tiếp.
- Campaign, paid-media hoặc partner links phụ thuộc vào routes cũ.
Cách phòng tránh
Xem mỗi source path là quan hệ giữa route cũ, đối tượng dữ liệu đích, phạm vi, loại redirect và canonical path dự kiến. Cập nhật internal links và media references theo nơi tiếp nhận trên đích. Giữ CMS content, Page Builder layout và URL history thành các phần riêng.
Tình huống minh họa
Dùng một bản ghi Products đã đổi URL, một bản ghi Categories đã chuyển vị trí trong hệ thống phân cấp và một CMS Page bản địa hóa. Giữ canonical destination cùng mọi source paths còn quan trọng với hoạt động kinh doanh.
Điều kiện đạt
Mỗi legacy path đại diện đưa người dùng tới đúng đích trong đúng phạm vi, internal links và media hoạt động chính xác, đồng thời content bị giới hạn hoặc bản địa hóa không bị chuyển hướng sang sai website hay store view.
Sai lầm 9: Giữ totals của Orders nhưng làm mất ngữ cảnh company và xử lý đơn hàng
Vấn đề xảy ra
Orders trước đây có thể giữ đúng tổng tiền nhưng mất company ownership, purchaser role, shared-catalog context, quan hệ với quote hoặc Purchase Orders, source items, shipments, invoices, refunds và external transaction identifiers. Khi đó nhân sự chỉ nhìn thấy một bản ghi tài chính nhưng không đủ cơ sở để hỗ trợ người mua hoặc đối chiếu giao dịch.
Dấu hiệu cảnh báo sớm
- B2B Orders chỉ được liên kết với từng Customers riêng lẻ.
- Dòng hàng Orders không xác định được configurable child hoặc bundle component ban đầu.
- Shipment và refund records được lưu tách khỏi file export Orders.
- ERP hoặc payment references chỉ tồn tại trong extension tables.
Cách phòng tránh
Giữ phần đầu của Orders, company và buyer identity, addresses, line snapshots, selected options, prices, discounts, taxes, tham chiếu shared catalog hoặc quote, invoices, shipments, refunds, comments và external IDs. Giữ historical snapshots độc lập với cấu hình Products và company hiện tại.
Tình huống minh họa
Dùng một bản ghi Orders của company được tạo từ quote, một bản ghi Orders mới xử lý một phần shipment và một bản ghi Orders đã refund có Configurable Products. Lần theo mọi bản ghi liên quan về đúng Orders gốc.
Điều kiện đạt
Mỗi bản ghi Orders đại diện vẫn có thể được bộ phận chăm sóc Customers, finance và operations hiểu rõ, với ngữ cảnh đầy đủ về company, buyer, Products, payment, shipment, refund và hệ thống bên ngoài.
Sai lầm 10: Sao chép các trường của extensions và các tích hợp nhưng làm mất quy tắc sở hữu
Vấn đề xảy ra
Hệ thống Adobe Commerce thường có modules, custom attributes, custom tables, APIs, event observers, ERP và PIM identifiers, marketplace records, tax các tích hợp, dữ liệu xử lý đơn hàng và các trường trong checkout được tùy chỉnh. Sao chép các giá trị này vào các trường chung không giữ được quy trình tạo, cập nhật hoặc sử dụng chúng.
Nền tảng đích có thể chứa dữ liệu nhưng mọi hệ thống kết nối vẫn xem dữ liệu đó là thiếu hoặc đã lỗi thời.
Dấu hiệu cảnh báo sớm
| Dấu hiệu cảnh báo sớm | Điều dấu hiệu này cho thấy |
|---|---|
| Giá trị quan trọng có module prefixes hoặc nằm trong custom tables. | Dữ liệu nhiều khả năng do quy tắc của extension sở hữu thay vì một đối tượng dữ liệu tiêu chuẩn. |
| Hệ thống bên ngoài nhận diện Products, companies, Customers hoặc Orders bằng nonstandard keys. | Việc duy trì hoạt động giữa các hệ thống phụ thuộc vào identifiers ngoài các trường mặc định. |
| Các giá trị hợp lệ của một trường được code kiểm soát thay vì cấu trúc database. | Chỉ sao chép giá trị không giữ được quy tắc áp dụng cho trường đó. |
| Nhân sự không xác định được hệ thống nào quản lý chính cho trường. | Xung đột quyền sở hữu có thể khiến giá trị bị ghi đè hoặc bỏ qua. |
Cách phòng tránh
Lập bảng quyền sở hữu cho từng bản ghi của extensions và các tích hợp. Ghi rõ bản ghi cha, source table hoặc API, external key, hệ thống quản lý chính, hướng cập nhật và nơi tiếp nhận trên đích. Loại phần dư kỹ thuật không còn dùng thay vì biến chúng thành các trường tùy chỉnh tồn tại lâu dài.
Tình huống minh họa
Lần theo một bản ghi Products từ PIM tới Adobe Commerce, một company từ CRM và một bản ghi Orders tới ERP cùng hệ thống xử lý đơn hàng. Ghi rõ identifiers và ranh giới quyền sở hữu cần thiết ở từng bước.
Điều kiện đạt
Mỗi custom value hoặc giá trị từ các tích hợp được giữ lại đều có nơi tiếp nhận xác định, parent relationship ổn định, hệ thống quản lý chính và identifier dùng được giữa các hệ thống; không có quy trình thiết yếu nào phụ thuộc vào trường không còn chủ sở hữu.
Các ưu tiên phòng tránh xuyên suốt
Để phòng tránh lỗi trên Adobe Commerce, cần giữ năm nhóm quan hệ kết nối với nhau: company identity, quy tắc thương mại theo người mua, dữ liệu storefront theo phạm vi, quan hệ Products với inventory và quyền sở hữu của hệ thống bên ngoài. Sửa một nhóm không được âm thầm làm hỏng nhóm khác. Ví dụ, xây dựng lại shared catalog cũng ảnh hưởng company assignment, quyền truy cập Categories, price indexing và storefront access.
| Nhóm cần kiểm soát | Yêu cầu |
|---|---|
| Company và buyer identity | Giữ company, location, role, approval và quan hệ Customers kết nối với nhau. |
| Phân bổ thương mại | Giữ shared catalog, company assignment, variant price và ngữ cảnh purchasing rules cùng nhau. |
| Dữ liệu storefront theo phạm vi | Duy trì đúng website, store và store-view ownership cho Products, content, URLs và Customers. |
| Content theo thời gian | Tách trạng thái đang hoạt động khỏi scheduled campaign versions và các thay đổi phối hợp. |
| Quyền sở hữu bên ngoài | Gán extension các trường, custom tables và external identifiers cho hệ thống quản lý chính tương ứng. |
Kết luận
Chuyển đổi Adobe Commerce trở nên thiếu tin cậy khi quan hệ doanh nghiệp bị thu gọn thành các trường dữ liệu commerce thông thường. Companies, roles, shared catalogs, quotes, purchase orders, giá trị theo phạm vi, content campaigns, inventory sources, Orders trước đây, URL rewrites và identifiers dùng cho các tích hợp đều cần chủ sở hữu rõ ràng.
Cách an toàn nhất là xem mỗi sai lầm như một quan hệ bị đứt, không chỉ như một dòng dữ liệu bị thiếu. Khi các bản ghi cha, commercial rules, scopes, histories và external keys vẫn được kết nối, Cửa hàng đích mới có thể hỗ trợ các quy trình doanh nghiệp mà những dữ liệu này vốn phục vụ.
Câu hỏi thường gặp
Vì sao company users trên Adobe Commerce không tương đương Customers thông thường?
Company users nhận ngữ cảnh nghiệp vụ từ company account, gồm roles, permissions, shared catalogs và purchasing workflows. Một bản ghi Customers riêng lẻ không giữ được các quan hệ ở cấp tổ chức này.
Có thể chuyển shared-catalog pricing thành pricing Products thông thường không?
Không nên gộp shared-catalog pricing vào pricing Products chung. Mức giá của shared catalog thuộc quan hệ catalog và company cụ thể. Đưa các giá trị đó vào pricing chung có thể làm lộ negotiated values cho người mua không được phép hoặc khiến companies cần được hưởng mức giá đó không còn nhận đúng giá.
Vì sao phải giữ riêng phạm vi website, store và store view?
Hệ thống phân cấp này có thể kiểm soát phân bổ Products, root Categories, giá trị bản địa hóa, URLs, cấu hình và ngữ cảnh thương mại. Một giá trị global có thể ghi đè hoặc làm lộ thông tin vốn được chủ động giới hạn theo phạm vi.
Content Staging khác CMS content thông thường ở điểm nào?
Content Staging giữ baseline values, scheduled updates, campaign grouping, timing và cách trở về trạng thái sau campaign. Giá trị đang hiển thị chỉ là một thời điểm trong toàn bộ timeline đó.
Vì sao source quantity chưa đủ để xác định inventory trên Adobe Commerce?
Ý nghĩa của inventory phụ thuộc physical source, stock tổng hợp sources, sales channel hoặc website, status và hệ thống tiếp tục quản lý chính. Chỉ một con số quantity không xác định hàng nằm ở đâu hay có thể được xử lý theo cách nào.
Dữ liệu Adobe Commerce do extensions sở hữu nên được xử lý như thế nào?
Cần xác định module hoặc hệ thống bên ngoài, đối tượng dữ liệu core được mở rộng, identifier ổn định và quy trình sử dụng giá trị. Chỉ giữ các bản ghi có nơi tiếp nhận rõ trên đích và còn mục đích nghiệp vụ tiếp tục sử dụng.