Next-Cart

Những sai lầm thường gặp khi chuyển đổi sang Shift4Shop và cách phòng tránh

Khi chuyển đổi sang Shift4Shop, vấn đề thường khó phát hiện vì storefront có thể trông đầy đủ trước khi các quy tắc bán hàng bên dưới được thể hiện đúng. Products có thể xuất hiện nhưng tồn kho theo options bị sai. Customers có thể tồn tại nhưng quyền truy cập theo nhóm và Price Levels bị tách rời. Orders có thể đọc được nhưng nhân viên không hiểu đầy đủ trạng thái, discounts hoặc lịch sử xử lý giao hàng. Cách phòng tránh đáng tin cậy nhất là đánh giá chức năng và quan hệ mà từng bản ghi mang theo, không chỉ kiểm tra bản ghi có xuất hiện hay không.

Các tình huống dưới đây tập trung vào những lỗi thường lặp lại khi Shift4Shop là Nền tảng đích. Mỗi tình huống nêu hệ quả vận hành, dấu hiệu cảnh báo sớm, cách phòng tránh, một trường hợp minh họa và điều kiện chứng minh lỗi đó đã được kiểm soát.

Sai lầm 1: Coi options của Products và Advanced Options là cùng một cấu trúc

Vấn đề xảy ra

Các lựa chọn của Products ở nguồn được chuyển thành options thông thường dù một số tổ hợp có SKU, GTIN, tồn kho, trọng lượng, cost hoặc giá riêng. Storefront vẫn hiển thị lựa chọn nhưng inventory, shipping, procurement hoặc reporting lại dùng giá trị của Products gốc thay vì tổ hợp được chọn.

Shift4Shop có thể dùng options của Products cho lựa chọn của Customers và Advanced Options cho dữ liệu thương mại ở cấp tổ hợp. Làm phẳng hai cấu trúc thành một lớp sẽ xóa mất khác biệt giữa lựa chọn chỉ dùng để hiển thị và cấu hình có thể bán được quản lý độc lập.

Dấu hiệu cảnh báo sớm

Dấu hiệu Hệ quả có thể xảy ra
Một variant ở nguồn có SKU hoặc tồn kho riêng Chỉ được tạo thành option hiển thị
Tổ hợp options thay đổi trọng lượng hoặc cost Shipping và báo cáo biên lợi nhuận dùng giá trị Products gốc
Nhóm Customers khác nhau phải nhận giá options khác nhau Một mức điều chỉnh được áp dụng cho mọi Price Levels
Nguồn có tổ hợp bị vô hiệu hóa hoặc không khả dụng Shift4Shop cho phép bán những tổ hợp không nên xuất hiện

Cách phòng tránh

Phân loại từng lựa chọn của Products theo dữ liệu mà lựa chọn đó kiểm soát. Dùng options thông thường khi lựa chọn không cần được theo dõi độc lập. Dùng Advanced Options khi tổ hợp cần tồn kho, identifier, trọng lượng, cost hoặc thuộc tính thương mại riêng.

Ghi rõ trường hợp điều chỉnh giá options dùng chung và trường hợp phải xử lý riêng theo nhóm. Không giả định giá Products gốc cộng một mức tăng duy nhất có thể tái tạo mọi quy tắc giá ở nguồn.

Tình huống minh họa

Với Products thời trang có size và color, chọn ít nhất một tổ hợp còn hàng, một tổ hợp bị vô hiệu hóa và một tổ hợp có trọng lượng hoặc giá khác. Xác nhận lựa chọn tạo đúng SKU, tồn kho và chi tiết mặt hàng trong Orders.

Điều kiện đạt

Các tổ hợp đại diện giữ đúng khả năng bán, identifiers, giá, tồn kho, trọng lượng và chi tiết Orders tương ứng, đồng thời không sinh tổ hợp trùng hoặc không có thật.

Sai lầm 2: Giữ Categories nhưng làm suy yếu khả năng người mua tìm Products

Vấn đề xảy ra

Tên Categories được chuyển nhưng storefront không còn dẫn người mua qua những đường khám phá tương đương. Quan hệ cha-con, Products thành viên, quy tắc hiển thị, SmartCategory, vị trí menu, breadcrumbs và routes ưu tiên có thể lệch dù mọi bản ghi Categories đều tồn tại.

Lỗi này đặc biệt dễ bị bỏ qua khi Cửa hàng nguồn dùng nhóm động hoặc nhóm được tuyển chọn thủ công thay vì hierarchy tĩnh đơn giản.

Dấu hiệu cảnh báo sớm

Thành phần khám phá Dấu hiệu
Categories cha Categories con xuất hiện sai cấp hoặc không có landing page hữu ích
SmartCategories Quy tắc thành viên bị thay bằng danh sách Products tại một thời điểm
Categories giới hạn theo nhóm Categories hiển thị cho sai nhóm Customers
Search và navigation Products quan trọng có mặt nhưng khó tiếp cận
Routes kế thừa URL Categories cũ không có đích phù hợp

Cách phòng tránh

Lập bản đồ Categories theo mục đích: navigation, merchandising, kiểm soát truy cập, nhóm chiến dịch hoặc landing page SEO. Chỉ giữ hierarchy khi còn hỗ trợ Cửa hàng đích. Tái tạo quan hệ động hoặc được tuyển chọn khi import tĩnh sẽ nhanh chóng trở nên lỗi thời.

Tạo sơ đồ route và đường khám phá cho Categories mang doanh thu, lưu lượng tự nhiên hoặc quyền truy cập hạn chế. Menu và breadcrumbs là phần trình bày tại Nền tảng đích, không nên giả định tự hình thành chỉ từ bản ghi Categories.

Tình huống minh họa

Chọn một đường Categories nhiều tầng, một SmartCategory hoặc nhóm được duy trì động và một nhóm Categories bị giới hạn theo nhóm. Theo dõi cách người mua đi đến từng trang và Products nào cần xuất hiện.

Điều kiện đạt

Products ưu tiên vẫn được tìm thấy qua đúng Categories, search, menu và breadcrumbs; các nhóm bị giới hạn hoặc động tiếp tục phục vụ đúng mục đích kinh doanh.

Sai lầm 3: Chuyển nhóm Customers nhưng bỏ rời quy tắc giá và quyền truy cập

Vấn đề xảy ra

Customers được gán vào nhóm nhưng Price Level, mức đơn tối thiểu, quyền xem Products, quyền xem Categories, quyền truy cập nội dung, payment hoặc shipping gắn với nhóm không được thiết lập lại. Tên nhóm còn tồn tại nhưng cách doanh nghiệp phục vụ người mua đã thay đổi.

Nhóm Customers của Shift4Shop có thể liên kết với Price Levels và giới hạn truy cập. Vì vậy, nhóm không chỉ là phân đoạn; nhóm có thể quyết định Customers thấy gì và mua theo điều kiện nào.

Dấu hiệu cảnh báo sớm

Mối quan hệ của nhóm Biểu hiện lỗi
Price Level Customers đăng nhập nhưng thấy giá retail
Quyền xem Products/Categories Hàng hóa giới hạn trở thành công khai hoặc biến mất với người mua hợp lệ
Mức Orders tối thiểu Customers wholesale có thể checkout dưới ngưỡng dự kiến
Payment hoặc shipping Nhóm đến checkout nhưng không có phương thức hợp lệ
Tax Nhóm bị tính hoặc miễn Tax sai

Cách phòng tránh

Tạo ma trận quy tắc nhóm Customers, kết nối mỗi nhóm với Price Level, kiểm soát truy cập, yêu cầu checkout, cách xử lý Tax và mục đích giao tiếp. Chỉ gán Customers sau khi các quy tắc tại Nền tảng đích đã được xác định.

Nếu nguồn dùng giá riêng theo từng tài khoản thay vì giá theo nhóm, cần giữ rõ khác biệt đó. Không gom các bảng giá đã thương lượng vào một nhóm rộng hơn nếu doanh nghiệp chưa phê duyệt thay đổi.

Tình huống minh họa

Dùng một tài khoản Customers retail, một tài khoản Customers wholesale và một tài khoản Customers có quyền truy cập hạn chế. Kiểm tra Products, Categories, giá, mức Orders tối thiểu, Tax và các phương thức checkout mỗi tài khoản phải nhận.

Điều kiện đạt

Các tài khoản Customers đại diện nhận đúng Price Level, quyền truy cập catalog, mức Orders tối thiểu, cách xử lý Tax cùng phương thức shipping và payment sau khi đăng nhập.

Sai lầm 4: Làm phẳng giá theo số lượng, discounts, Coupons và giá trị gift

Vấn đề xảy ra

Quy tắc thương mại được giữ dưới dạng tên hoặc số tiền lịch sử nhưng điều kiện kích hoạt bị mất. Mức giá theo số lượng có thể áp dụng sai nhóm, Coupons có thể bỏ qua giới hạn Products/Categories, điều chỉnh giá options có thể tính khác hoặc lịch sử gift certificates bị hiểu nhầm thành số dư còn hiệu lực.

Một bản ghi discount nhìn thấy được không chứng minh phép tính tại Nền tảng đích giống nguồn. Cần hiểu phạm vi, điều kiện đủ, thứ tự áp dụng và bên tiếp tục chịu trách nhiệm cho từng quy tắc.

Dấu hiệu cảnh báo sớm

Quy tắc thương mại Dấu hiệu
Giá theo số lượng Chỉ một bậc số lượng được kiểm tra
Giá theo nhóm Customers Mọi nhóm thấy cùng giá Products
Coupons Code hoạt động nhưng bỏ qua exclusions hoặc ngưỡng
Gift certificate Codes lịch sử bị coi là nghĩa vụ tài chính đang hoạt động mà chưa reconciliation
Điều chỉnh giá option Mức tăng đúng cho retail nhưng sai với Price Level khác

Cách phòng tránh

Kiểm kê mọi quy tắc làm thay đổi số tiền người mua phải trả. Ghi Customers đủ điều kiện, phạm vi Products/Categories, ngưỡng số lượng, khoảng thời gian, cách kết hợp quy tắc và bên chịu trách nhiệm. Tách thông tin lịch sử khỏi số dư hoặc phép tính đang hoạt động.

Nếu Shift4Shop cần cấu trúc quy tắc khác, hãy xác định kết quả kinh doanh dự kiến thay vì sao chép nguyên cấu hình nguồn.

Tình huống minh họa

Dùng một giỏ hàng gồm Products có giá theo số lượng, một khoản tăng do option và một mã Coupons có giới hạn điều kiện. So sánh kết quả mong đợi cho cả Customers retail và wholesale.

Điều kiện đạt

Các giỏ hàng đại diện cho ra tổng tiền có thể giải thích và đã được phê duyệt; nghĩa vụ gift, Coupons và chính sách giá đang hoạt động được reconciliation rõ ràng thay vì suy ra từ bản ghi lịch sử.

Sai lầm 5: Giữ Orders nhưng làm mất ngữ cảnh nhân viên cần sử dụng

Vấn đề xảy ra

Orders được chuyển với mã, ngày, Customers và tổng tiền nhưng nhân viên mất lịch sử trạng thái, nhãn payment, shipping method, tracking reference, giải thích discount, ghi chú nội bộ, quan hệ CRM hoặc ngữ cảnh ngoại lệ cần để hỗ trợ người mua.

Lỗi này thường bị bỏ qua khi chỉ lấy Orders hoàn tất làm mẫu. Orders canceled, refunded, partially shipped, điều chỉnh thủ công hoặc wholesale thường chứa các tình huống làm lộ mapping yếu.

Dấu hiệu cảnh báo sớm

Bản ghi Orders đại diện Rủi ro bị che khuất
Orders retail hoàn tất Trường cơ bản đạt nhưng cách xử lý ngoại lệ chưa được kiểm tra
Orders có discount Tổng tiền có nhưng lý do điều chỉnh bị mất
Orders wholesale Không thấy ngữ cảnh nhóm và Price Level
Orders refunded hoặc canceled Trạng thái và thông tin payment bị làm phẳng
Orders liên kết CRM hoặc affiliate Nhân viên không theo được lịch sử liên quan

Cách phòng tránh

Xác định mục đích đã được phê duyệt cho lịch sử đơn hàng và thông tin cần giữ để đáp ứng mục đích đó. Duy trì Products dễ đọc, options đã chọn, liên kết Customers, tổng tiền, Tax, discounts, trạng thái, shipping, tracking, nhãn payment và notes liên quan.

Mapping trạng thái nguồn sang ý nghĩa lịch sử rõ ràng. Không gán trạng thái vận hành đang hoạt động cho một đơn hàng được import nếu cửa hàng không chủ ý muốn nhân viên tiếp tục xử lý bản ghi đó.

Tình huống minh họa

Rà soát một đơn hàng thông thường, một đơn hàng wholesale, một đơn hàng có discount, một đơn hàng refunded hoặc canceled và một đơn hàng chứa chi tiết options. Yêu cầu nhân viên giải thích điều đã xảy ra mà không cần mở Nền tảng nguồn.

Điều kiện đạt

Nhân viên có thể hiểu lịch sử đơn hàng đại diện, bao gồm ngoại lệ và ngữ cảnh thương mại, mà không nhầm bản ghi import với nhiệm vụ payment hoặc xử lý giao hàng đang hoạt động.

Sai lầm 6: Coi shipping, payment và câu hỏi checkout là dữ liệu Customers

Vấn đề xảy ra

Dự án giữ nhóm Customers và lịch sử đơn hàng nên đội ngũ giả định shipping methods, payment methods, checkout questions, quy tắc Tax và giới hạn mua hàng sẽ tự đi theo. Đây là cấu hình đang hoạt động của Store và có thể khác nhau theo từng nhóm Customers.

Vì vậy, một nhóm có thể trông đúng trong bản ghi Customers nhưng thành viên lại không có shipping method hợp lệ, nhận sai payment method hoặc thiếu thông tin bắt buộc tại checkout.

Dấu hiệu cảnh báo sớm

Mối phụ thuộc checkout Dấu hiệu
Shipping riêng theo nhóm Mọi phương thức chỉ được cấu hình cho nhóm mặc định
Payment riêng theo nhóm Customers wholesale không chọn được phương thức đã phê duyệt
Câu hỏi checkout Thông tin doanh nghiệp bắt buộc không được thu thập
Quy tắc giá trị mua tối thiểu Checkout tại Nền tảng đích không thực thi đúng ngưỡng
Nhóm miễn Tax Dữ liệu Customers có nhưng checkout vẫn tính Tax

Cách phòng tránh

Duy trì ma trận trách nhiệm cho checkout đang hoạt động, tách khỏi bản ghi Customers và Orders được chuyển. Với mỗi nhóm Customers, xác định payment/shipping methods khả dụng, mức Orders tối thiểu, cách xử lý Tax và câu hỏi checkout bắt buộc.

Không dùng nhãn payment hoặc shipping trong lịch sử đơn hàng như chỉ dẫn cấu hình nếu chưa xác nhận các phương thức đó vẫn còn phù hợp với Cửa hàng đích.

Tình huống minh họa

Hoàn tất một phiên checkout đại diện bằng Customers retail và một phiên bằng Customers wholesale. Hai phiên phải hiển thị đúng catalog, giá, shipping, payment, Tax và các câu hỏi bắt buộc.

Điều kiện đạt

Mỗi nhóm Customers đang hoạt động có thể hoàn tất đúng luồng checkout với ít nhất một shipping method và payment method hợp lệ, cùng các giới hạn và câu hỏi đúng.

Sai lầm 7: Coi nội dung và SEO chỉ là bài toán redirect

Vấn đề xảy ra

Đội dự án lập bản đồ URLs cũ nhưng không giữ nội dung, hierarchy, metadata, internal links hoặc mục đích của trang đích đối với người mua. Routes Products và Categories có thể redirect thành công trong khi landing pages, information pages, Blog và đường chiến dịch biến mất hoặc dẫn đến trang không liên quan.

Redirect chỉ bảo vệ tính liên tục khi đích đến vẫn đáp ứng ý định ban đầu. Một redirect kỹ thuật thành công về homepage vẫn có thể làm suy yếu khả năng khám phá Products và tỷ lệ người mua hoàn tất giao dịch.

Dấu hiệu cảnh báo sớm

Loại trang Rủi ro
Trang Products Products đích khác hoặc thiếu nội dung quan trọng
Trang Categories Hierarchy tồn tại nhưng trang không còn hỗ trợ khám phá Products
Trang thông tin Chính sách, hỗ trợ hoặc hướng dẫn mua hàng bị thiếu
Trang nội dung giới hạn Quy tắc truy cập bị mất khi tạo lại route
Landing page chiến dịch Link cũ mở được nhưng offer hoặc ngữ cảnh không còn

Cách phòng tránh

Phân loại URLs ưu tiên theo loại trang, giá trị lưu lượng, backlinks, mục đích chiến dịch và ý định đích. Kết nối quyết định route với quyết định nội dung. Tái tạo hoặc hợp nhất trang trước khi bật redirects để đích đến đã có ý nghĩa.

Giữ internal links và tham chiếu navigation trỏ đến nội dung ưu tiên. Chủ động ngừng sử dụng trang lỗi thời thay vì để phát sinh lỗi ngoài ý muốn.

Tình huống minh họa

Lập bản đồ một URL Products có lưu lượng cao, một URL Categories, một trang thông tin wholesale và một landing page chiến dịch. Mỗi đường dẫn cần tới đích hỗ trợ cùng mục đích của người mua.

Điều kiện đạt

URLs ưu tiên ở nguồn dẫn đến đích Shift4Shop có liên quan, đã xuất bản và truy cập được, tiếp tục đáp ứng ý định ban đầu và không dùng redirect hàng loạt để che nội dung bị thiếu.

Sai lầm 8: Trộn trường gốc, dữ liệu tùy chỉnh và giá trị do hệ thống tích hợp sở hữu

Vấn đề xảy ra

Trường Shift4Shop hoặc trường kế thừa từ 3dcart, trường tùy chỉnh, ERP identifiers, thuộc tính marketplace và giá trị chỉ phục vụ reporting bị chép vào trường đích gần nhất. Dữ liệu vẫn nhìn thấy được nhưng mất cấp bản ghi, định dạng hoặc quyền sở hữu mà nhân viên và hệ thống tích hợp đang cần.

Cùng một nhãn có thể đại diện cho trường gốc của Shift4Shop, trường tùy chỉnh, giải pháp tạm thời không còn dùng hoặc giá trị do hệ thống bên ngoài duy trì. Coi chúng tương đương có thể gây lỗi đồng bộ và reporting.

Dấu hiệu cảnh báo sớm

Loại dữ liệu Rủi ro quyền sở hữu
Trường Products gốc Bị dùng lại cho metadata bên ngoài không liên quan
Trường tùy chỉnh Không xác định nhân viên hoặc hệ thống tích hợp tiếp tục sử dụng
ERP hoặc marketplace ID Bị chuyển từ cấp variant lên Products gốc
Tham chiếu kế thừa từ 3dcart Giá trị mô tả quy tắc cũ không còn tồn tại
Trường báo cáo tùy chỉnh Báo cáo tại Nền tảng đích không đọc vị trí dữ liệu sau di chuyển dữ liệu

Cách phòng tránh

Tạo bảng theo dõi quyền sở hữu trường, gồm bản ghi nguồn, bản ghi đích, định dạng dự kiến, hệ thống tiếp tục sử dụng, bên có quyền ghi và quyết định ngừng sử dụng. Giữ external identifiers đúng cấp bản ghi mà hệ thống tích hợp đang tiếp tục sử dụng.

Không chuyển một giá trị chỉ vì có thể lấy được. Loại bỏ trường lỗi thời và tái dựng quy tắc còn hoạt động trong hệ thống sẽ chịu trách nhiệm cho quy tắc đó.

Tình huống minh họa

Với một dòng sản phẩm kết nối ERP, theo dõi ID Products gốc, SKU của option hoặc Advanced Option, hệ thống chịu trách nhiệm inventory và identifier trong chi tiết Orders xuyên suốt Nền tảng đích. Xác nhận ERP đọc đúng các quan hệ sau khi chuyển sang vận hành chính thức.

Điều kiện đạt

Mọi giá trị tùy chỉnh hoặc do hệ thống tích hợp sở hữu được giữ lại đều có hệ thống sử dụng rõ ràng, đúng cấp bản ghi, định dạng ổn định, đường reporting tại Nền tảng đích và bên có quyền ghi không mơ hồ sau khi vận hành chính thức.

Sai lầm 9: Tái tạo giao diện theme và app nhưng không tái tạo các mối phụ thuộc dữ liệu

Vấn đề xảy ra

Theme tại Nền tảng đích có thể giống Cửa hàng nguồn về hình thức nhưng app, feed, script tùy chỉnh, trường Products, quy tắc Categories hoặc khối nội dung tạo nên trải nghiệm lại bị thiếu. Search, recommendations, nhãn Products, Reviews, feeds hoặc nội dung giới hạn khi đó có thể không đầy đủ hoặc trở thành dữ liệu tĩnh.

Cách trình bày thường là kết quả cuối cùng của nhiều quan hệ dữ liệu. Sao chép markup hoặc design không tái tạo những quan hệ đó.

Dấu hiệu cảnh báo sớm

Thành phần ở nguồn Mối phụ thuộc bị che khuất
Nhãn Products Trường Products tùy chỉnh hoặc quy tắc cung cấp giá trị
Landing page đã lọc SmartCategory hoặc script kiểm soát Products thành viên
Hiển thị Reviews Identifiers Products nối bản ghi Reviews
Marketplace feed Thuộc tính bắt buộc đến từ trường tùy chỉnh hoặc dữ liệu ở cấp option
Nội dung riêng theo nhóm Quy tắc bảo mật nhóm Customers kiểm soát khả năng hiển thị

Cách phòng tránh

Kiểm kê theme components và apps theo dữ liệu chúng sử dụng. Quyết định mỗi mối phụ thuộc sẽ trở thành cấu hình gốc của Shift4Shop, app, trường tùy chỉnh, hệ thống tích hợp hay chức năng không tiếp tục duy trì. Tái dựng luồng dữ liệu trước khi tái tạo phần trình bày.

Loại bỏ scripts lỗi thời thay vì mang sang Nền tảng đích mà không có chủ thể chịu trách nhiệm.

Tình huống minh họa

Chọn một trang Products quan trọng về doanh thu có Reviews, filters, badges và dữ liệu options. Xác định mọi trường nguồn hoặc app điều khiển trải nghiệm nhìn thấy được, sau đó xác nhận chủ thể tại Nền tảng đích cho từng mối phụ thuộc.

Điều kiện đạt

Các thành phần storefront ưu tiên nhận dữ liệu hiện tại từ một chủ thể tại Nền tảng đích đã xác định và không phụ thuộc vào markup sao chép, scripts không còn chủ thể hoặc trường nguồn lỗi thời.

Bản đồ phòng tránh theo nhóm sai lầm

Hạng mục kiểm soát Sai lầm được kiểm soát Kết quả cần đạt
Mô hình quan hệ Products 1, 2, 4 options, Advanced Options, Categories và quy tắc giá giữ đúng ý nghĩa bán hàng
Ma trận cách phục vụ Customers 3, 6 Nhóm, Price Levels, quyền truy cập, Tax, shipping, payment và checkout tiếp tục liên kết
Mô hình lịch sử đơn hàng 5 Orders vẫn hiểu được mà không bị biến thành nhiệm vụ vận hành đang hoạt động
Danh sách routes và nội dung 2, 7 Khả năng khám phá Products và các đường truy cập ưu tiên từ bên ngoài vẫn có chủ đích
Quyền sở hữu trường và mối phụ thuộc 8, 9 Dữ liệu tùy chỉnh, apps, themes và các hệ thống tích hợp đều có chủ thể tiếp tục chịu trách nhiệm

Kết luận

Chất lượng chuyển đổi sang Shift4Shop phụ thuộc vào việc giữ đúng các kết nối giữa cấu trúc Products, cách phục vụ Customers, quy tắc thương mại, cấu hình Store và thông tin vận hành. Catalog nhìn đầy đủ vẫn chưa đủ nếu options, Price Levels, quyền truy cập checkout hoặc dữ liệu do app sở hữu hoạt động sai. Khi mỗi sai lầm có chủ thể chịu trách nhiệm, tình huống đại diện và điều kiện đạt rõ ràng, Cửa hàng đích có thể duy trì đúng cách kinh doanh mà không biến phân tích rủi ro thành một checklist chung chung.

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

Vì sao cửa hàng Shift4Shop có thể trông đầy đủ nhưng vẫn vận hành sai về mặt thương mại?

Bản ghi nhìn thấy được không chứng minh tồn kho ở cấp option, giá theo nhóm Customers, quyền truy cập Categories, discounts, shipping hoặc payment vẫn được kết nối đúng. Những quan hệ này cần được kiểm tra riêng.

Khi nào một variant ở nguồn nên trở thành Advanced Option?

Dùng Advanced Option khi tổ hợp cần SKU, tồn kho, trọng lượng, cost, GTIN hoặc dữ liệu thương mại riêng. Một lựa chọn chỉ dùng để hiển thị có thể tiếp tục là option thông thường của Products.

Vì sao nhóm Customers là hạng mục quan trọng trong chuyển đổi?

Nhóm có thể kiểm soát Price Levels, mức Orders tối thiểu, quyền truy cập catalog, Tax, nội dung, payment và shipping. Chỉ chuyển tên nhóm mà không giữ các quan hệ này sẽ thay đổi cách doanh nghiệp phục vụ người mua.

Gift certificates trong lịch sử có nên được coi là số dư đang hoạt động không?

Không nên suy ra số dư đang hoạt động chỉ từ lịch sử. Nghĩa vụ tài chính còn hiệu lực cần được đối chiếu và thiết lập có chủ đích. Bản ghi Orders trước đây không tự chứng minh một code hoặc số dư vẫn còn giá trị.

Điều gì khiến các trường kế thừa từ 3dcart trở thành rủi ro khi chuyển sang Shift4Shop?

Cần xác định từng trường là trường gốc, trường tùy chỉnh, giá trị do hệ thống tích hợp sở hữu, trường chỉ phục vụ reporting hay dữ liệu lỗi thời. Chỉ giữ những giá trị có bản ghi đích và hệ thống tiếp tục sử dụng rõ ràng.

Các mối phụ thuộc của theme và app nên được xử lý thế nào khi chuyển sang Shift4Shop?

Xác định dữ liệu mà từng theme component, app, feed hoặc script tùy chỉnh đang sử dụng, sau đó giao trách nhiệm tiếp tục cho cấu trúc Shift4Shop phù hợp hoặc một hệ thống bên ngoài. Tái dựng luồng dữ liệu cần thiết trước khi tái tạo phần trình bày, đồng thời loại bỏ scripts hoặc trường không còn phục vụ mô hình vận hành tại Nền tảng đích.