Khi chuyển dữ liệu sang Shift4Shop, mục tiêu không chỉ là đưa bản ghi từ cửa hàng nguồn sang Nền tảng đích. Dữ liệu cần được diễn giải theo cách Shift4Shop tổ chức Products, nội dung storefront, Customers, Orders, giá, URL phục vụ SEO và các quy tắc kinh doanh. Câu hỏi khó hơn là liệu những bản ghi sau chuyển đổi còn giữ đúng ý nghĩa ban đầu khi được sử dụng trong một cửa hàng Shift4Shop hosted hay không.
Nhiều nền tảng nguồn lưu ý nghĩa thương mại ở những vị trí khác nhau. Lựa chọn của Products có thể nằm trong attributes, variants, option sets, các trường tùy chỉnh, bản ghi ứng dụng, script hoặc layout phụ thuộc vào theme. Giá dành cho Customers có thể được điều khiển bằng nhóm, các mức giá, ghi chú tùy chỉnh, mã định danh ERP, quy tắc Coupons hoặc quy trình thủ công của nhân viên. Nội dung storefront có thể nằm trong trang Products, Categories, CMS Pages, Blog Posts, landing pages, cấu trúc menu hoặc block của page builder. Một dự án chuyển sang Shift4Shop có cấu trúc rõ ràng phải phân loại những ý nghĩa này trước khi quyết định chúng sẽ được thể hiện ở đâu trên Nền tảng đích.
Shift4Shop thay đổi cách diễn giải dữ liệu như thế nào
Shift4Shop là nền tảng thương mại điện tử hosted, vì vậy nhiều quyết định cho cửa hàng tương lai được định hình bởi công cụ quản lý Products, quản trị storefront, SEO, chức năng dành cho Customers, promotions và khả năng kết nối với hệ thống bên ngoài có sẵn trên Nền tảng đích. Dữ liệu từng rất linh hoạt hoặc do đội ngũ phát triển tự kiểm soát ở cửa hàng nguồn có thể cần được đưa vào cấu trúc rõ ràng hơn trong Shift4Shop.
Khác biệt này ảnh hưởng trực tiếp đến cách đọc bản ghi trong dự án chuyển đổi. Một trường dữ liệu nguồn có thể trông giống thuộc tính mô tả Products nhưng thực tế lại kiểm soát cách người mua lựa chọn. Một ghi chú về Customers có thể trông như thông tin mô tả nhưng thực tế phản ánh trạng thái phê duyệt bán sỉ. Một bản ghi Categories có thể giống nhãn navigation nhưng lại mang giá trị SEO. Một trạng thái trong lịch sử đơn hàng có thể giống trạng thái Orders thông thường nhưng thực chất ghi lại một quy trình xử lý giao hàng tùy chỉnh không còn tồn tại dưới cùng hình thức ở Nền tảng đích.
| Ý nghĩa tại cửa hàng nguồn | Câu hỏi cần làm rõ khi chuyển sang Shift4Shop |
|---|---|
| Thuộc tính Products | Đây là thông tin mô tả, lựa chọn của người mua, dữ liệu phục vụ search/filter hay tham chiếu cho vận hành? |
| Lựa chọn Products | Nên trở thành options, Advanced Options, Products riêng hay cấu hình cần xây dựng lại trên Nền tảng đích? |
| Categories | Cấu trúc dùng cho duyệt Products, SEO, merchandising, tổ chức nội bộ hay chỉ là phần dư thừa của hệ thống nguồn? |
| Nhóm Customers | Chỉ dùng để phân khúc người mua hay còn kiểm soát giá, thuế, quyền truy cập và cách Orders được xử lý? |
| Discounts và quy tắc số lượng | Là quy tắc bán hàng đang hoạt động, chương trình cũ, chính sách bán sỉ hay campaign đã hết hiệu lực? |
| Trang nội dung | Phục vụ chuyển đổi, SEO, chính sách, giáo dục người mua hay chỉ duy trì navigation cũ? |
| Trường dữ liệu do hệ thống tích hợp sử dụng | Là trường gốc của nền tảng, mã định danh bên ngoài, giá trị do ứng dụng sở hữu hay tham chiếu cấu hình? |
Vì vậy, việc rà soát mô hình dữ liệu nên bắt đầu từ ý nghĩa kinh doanh. Khi ý nghĩa đã rõ, mỗi giá trị mới có thể được gắn vào bản ghi Products, option, Advanced Option, Categories, Customers, Orders, nội dung, trường tùy chỉnh hoặc mối quan hệ với hệ thống bên ngoài mà không ép những khái niệm khác nhau vào cùng một vị trí đích.
Products, options và Advanced Options
Dữ liệu Products trong Shift4Shop bao gồm bản ghi Products cốt lõi cùng options của Products, Advanced Options, option templates, tồn kho, hình ảnh, các trường bổ sung, Categories, giá theo số lượng và những mối quan hệ liên quan. Nhiều nền tảng nguồn gộp các khái niệm này dưới cùng nhãn như variant, attribute, modifier hoặc custom option. Trong Shift4Shop, không phải mọi lựa chọn đều mang cùng ý nghĩa.
option của Products đại diện cho lựa chọn của người mua. Advanced Options có thể gắn những giá trị thương mại cụ thể hơn vào từng tổ hợp, bao gồm giá, code, trọng lượng, tồn kho và dữ liệu tương tự variants. Các trường bổ sung của Products là trường thông tin, không phải tổ hợp để người mua lựa chọn. Option templates cho phép áp dụng lại một cấu trúc lựa chọn cho nhiều Products. Bundle hoặc Products được liên kết tạo thêm một loại quan hệ khác vì offer mà người mua mua có thể dựa trên nhiều bản ghi catalog riêng.
| Khái niệm tại hệ thống nguồn | Cách thể hiện phù hợp trong Shift4Shop | Ý nghĩa quan hệ cần giữ |
|---|---|---|
| Kích thước hoặc màu sắc tạo thành một tổ hợp bán được | option của Products kết hợp Advanced Option khi cần dữ liệu ở cấp tổ hợp | Lựa chọn của người mua liên kết với SKU, giá, tồn kho, trọng lượng, hình ảnh hoặc mã định danh chuẩn |
| Bộ options dùng chung | Option template | Cấu trúc lựa chọn dùng lại được mà không cần nhân bản các bản ghi Products không liên quan |
| Thông số kỹ thuật | trường bổ sung của Products, mô tả, tab hoặc nội dung thông tin khác | Dữ liệu mô tả không nên tạo ra tổ hợp có thể mua giả tạo |
| Bundle hoặc kit | Quan hệ giữa Products và các thành phần liên kết | Offer dành cho người mua liên kết với Products thành phần hoặc cách tính tồn kho |
| Digital Products | eProduct cùng file hoặc quyền tải xuống | Products được mua liên kết với nội dung tải xuống hoặc serial information |
| Một dòng sản phẩm được lưu thành nhiều SKU độc lập | Products độc lập hoặc cấu trúc options được hợp nhất | URL, Reviews, tồn kho, giá và lịch sử đơn hàng phải tiếp tục được hiểu rõ |
Câu hỏi quyết định là hệ thống nguồn nhận diện đơn vị có thể bán ở cấp nào. Khi tồn kho, giá, GTIN, hình ảnh hoặc cách xử lý giao hàng thay đổi theo từng tổ hợp, các giá trị đó thuộc cấp option/Advanced Option. Khi một trường chỉ mô tả Products, chuyển trường đó thành option sẽ tạo thêm cấu trúc thương mại không có thật.
Categories, SmartCategories và khả năng người mua tìm thấy Products
Categories trong Shift4Shop có thể tổ chức navigation, vị trí Products, breadcrumbs, khả năng xuất hiện trong tìm kiếm và merchandising. SmartCategories tạo ra một loại quan hệ khác: Products có thể được nhóm động theo điều kiện như trạng thái discount, thời điểm phát hành, cách xử lý vận chuyển hoặc keywords. Facets và filters trong Categories tạo thêm một lớp hỗ trợ khám phá Products.
Nền tảng nguồn có thể dùng Categories, collections, tags, menus, brands, saved searches hoặc campaign groups để đạt mục tiêu tương tự. Không nên sao chép những đối tượng này theo tên gọi. Vị trí đích phụ thuộc vào việc nhóm đó là hierarchy ổn định, quy tắc merchandising động, dimension dùng để lọc hay chỉ là menu link phục vụ trình bày.
| Cách nhóm tại hệ thống nguồn | Thành phần sở hữu trong Shift4Shop | Ý nghĩa cần giữ |
|---|---|---|
| Department hoặc taxonomy ổn định | Cây Categories | Quan hệ cha-con, quan hệ Products thuộc Categories, URL, metadata và ngữ cảnh breadcrumb |
| Nhóm sale, mới ra mắt hoặc free-shipping | SmartCategory hoặc quan hệ merchandising động tương ứng | Quan hệ phân nhóm dựa trên quy tắc thay vì gán Categories cố định trùng lặp |
| Thuộc tính kỹ thuật dùng để thu hẹp kết quả | Facet/filter | Ý nghĩa search và discovery mà không biến mọi giá trị thành hierarchy navigation |
| Brand hoặc manufacturer | Trường Products, Categories, facet hoặc quan hệ nội dung | Danh tính manufacturer và khả năng người mua tìm Products phải tách khỏi Categories thông thường |
| Link landing chỉ xuất hiện trong menu | Quan hệ navigation hoặc nội dung | URL công khai mà không tạo quan hệ cha-con giả trong catalog |
| Products nằm trong nhiều Categories | Quan hệ nhiều-nhiều của Products | Giữ mọi vị trí còn giá trị thương mại và ảnh hưởng SEO tương ứng |
Số lượng Products có thể giống nhau nhưng ý nghĩa discovery đã thay đổi. Mô hình đích cần giữ những quan hệ giải thích Products xuất hiện ở đâu, tại sao thuộc nhóm đó và quan hệ phân nhóm là cố định hay do điều kiện điều khiển.
Dữ liệu Customers, nhóm người mua và cách phục vụ từng nhóm
Bản ghi Customers trong Shift4Shop có thể liên kết với nhóm Customers, Price Levels, bảng giá riêng cho từng Customers, trường đăng ký, câu hỏi checkout, xử lý thuế, trạng thái mailing và lịch sử đơn hàng. Các quan hệ này tạo khác biệt giữa một bản ghi liên hệ đơn giản và một hồ sơ người mua có thể làm thay đổi cách cửa hàng bán hàng.
Nhóm Customers có thể tổ chức người mua và áp dụng Price Levels hoặc quy tắc truy cập. Bảng giá dành riêng cho từng Customers có thể tạo ngoại lệ ở cấp tài khoản. Các trường đăng ký bổ sung và câu hỏi checkout có thể chứa dữ liệu thuộc hồ sơ Customers, giao dịch cụ thể hoặc một nhóm người mua. Mã định danh từ ERP, CRM hoặc sales representative lại tạo thêm một lớp quyền sở hữu khác.
| Khái niệm người mua tại nguồn | Câu hỏi về cách thể hiện trong Shift4Shop | Ý nghĩa có nguy cơ mất |
|---|---|---|
| Tài khoản bán lẻ | Bản ghi Customers | Danh tính, địa chỉ, ngữ cảnh đăng nhập, lựa chọn liên lạc và lịch sử đơn hàng |
| Nhóm bán sỉ | Nhóm Customers kết hợp Price Level hoặc quy tắc liên quan | Giá và quyền truy cập gắn với một nhóm người mua |
| Giá hợp đồng riêng cho từng tài khoản | Bảng giá riêng của Customers hoặc quan hệ giá với hệ thống bên ngoài | Ngoại lệ ở cấp tài khoản không nên bị làm phẳng thành giá Products toàn cục |
| Người mua được miễn thuế | Phân loại Customers kết hợp tài liệu/quy tắc cấu hình thuế | Trạng thái người mua và cơ sở khiến trạng thái đó có hiệu lực |
| Trường đăng ký | Trường hồ sơ Customers hoặc dữ liệu intake theo nhóm | Thông tin người mua có tính lâu dài, khác với câu trả lời chỉ thuộc một bản ghi Orders |
| Câu hỏi checkout | Câu trả lời ở cấp Orders | Snapshot của giao dịch nên nằm cùng Orders thay vì trở thành danh tính lâu dài của Customers |
| Mã tài khoản bên ngoài | Trường tùy chỉnh hoặc quan hệ mapping | Khả năng đối chiếu với ERP, CRM, kế toán hoặc sales ownership |
Nền tảng đích cần giữ cách phục vụ người mua ở đúng cấp mà quy tắc được sở hữu. Một nhãn nhóm Customers không kèm Price Level hoặc quan hệ truy cập sẽ thiếu ý nghĩa; ngược lại, đưa câu trả lời checkout của một bản ghi Orders vào hồ sơ Customers có thể biến dữ liệu giao dịch thành thông tin lâu dài không chính xác.
Giá, discounts, Coupons và quy tắc theo số lượng
Dữ liệu giá hiếm khi chỉ là một trường price. Cửa hàng Shift4Shop có thể cần giá Products thông thường, sale price, quantity discounts, giá theo nhóm Customers, bảng giá riêng cho từng Customers, Coupons, gift certificates, quy tắc thuế, phụ phí liên quan đến vận chuyển hoặc quy tắc promotion. Hệ thống nguồn có thể định nghĩa những quy tắc này theo cách khác, đặc biệt khi promotions đến từ ứng dụng, module, code tùy chỉnh hoặc ERP.
Câu hỏi mô hình dữ liệu là mỗi quy tắc nên được chuyển như bản ghi, xây dựng lại trong Shift4Shop, ngừng sử dụng hay tiếp tục do hệ thống tích hợp kiểm soát. Các quy tắc thương mại đang hoạt động phải được ưu tiên vì ảnh hưởng trực tiếp đến doanh thu sau khi cửa hàng mới vận hành. Promotion lịch sử hoặc đã hết hiệu lực có thể hữu ích để tham chiếu, nhưng không nên trộn với những quy tắc phải tiếp tục chạy trên storefront mới.
| Loại quy tắc | Câu hỏi cần xem xét |
|---|---|
| Giá Products thông thường | Đây là giá bán đang áp dụng hay chỉ là giá nền cho quy tắc khác? |
| Sale price | Đang hoạt động, đã được lên lịch, đã hết hạn, dành riêng cho Customers hay thuộc campaign? |
| Quantity discount | Áp dụng cho mọi người mua, nhóm cụ thể, Customers B2B hay một dòng sản phẩm? |
| Coupons | Mã Coupons đang hoạt động, bị giới hạn, dùng lại được, dành riêng cho Customers hay chỉ là dữ liệu lịch sử? |
| Gift certificate | Là bản ghi Products, khoản giá trị dùng như phương thức thanh toán, mã riêng hay nghĩa vụ dịch vụ đối với Customers? |
| Bảng giá bên ngoài | Hệ thống nguồn của dữ liệu giá nằm trong cửa hàng, ERP, CRM hay hệ thống khác? |
Bản ghi giá cần được phân loại theo hệ thống sở hữu và vòng đời. Quy tắc đang hoạt động phải giữ đúng Products, nhóm Customers, số lượng, thời gian, Coupons và điều kiện áp dụng; quy tắc đã hết hạn có thể chỉ còn cần cho thông tin về các giao dịch trước đây hoặc được chủ động loại bỏ.
Orders, trạng thái và dữ liệu vận hành trước đây
Một bản ghi Orders trong Cửa hàng đích trên Shift4Shop là snapshot thương mại lịch sử. Những quan hệ hữu ích có thể bao gồm Customers hoặc guest, lựa chọn Products và options, giá từng dòng, discounts, thuế, vận chuyển, tham chiếu thanh toán, trạng thái, refunds, tracking, ghi chú, câu trả lời checkout và mã định danh của hệ thống bên ngoài.
Nền tảng nguồn thường dùng trạng thái Orders tùy chỉnh hoặc trạng thái xử lý đơn hàng do extension tạo ra. Những nhãn này cần được hiểu dựa trên điều đã thực sự xảy ra trong giao dịch thay vì sao chép như text độc lập. Nguyên tắc tương tự áp dụng cho tên phương thức thanh toán và vận chuyển: chúng giúp giải thích dữ liệu Orders trước đây nhưng không cấu hình payment gateway hoặc carrier đang hoạt động ở Nền tảng đích.
| Thành phần Orders | Quan hệ lịch sử cần giữ |
|---|---|
| Customers hoặc guest | Ai đặt Orders và tài khoản hoặc địa chỉ nào được sử dụng |
| Snapshot Products, options và Advanced Options | Đã mua gì, bao gồm tổ hợp người mua chọn và mã định danh tại nguồn |
| Giá, discount, thuế và tổng tiền | Kết quả tài chính tại thời điểm mua, không tính lại theo quy tắc hiện tại |
| Trạng thái và timeline | Trạng thái giao dịch cùng các sự kiện vòng đời quan trọng theo cách nhân viên có thể hiểu |
| Refund hoặc adjustment | Thay đổi so với snapshot tài chính ban đầu và lý do nếu có |
| Vận chuyển, tracking và tham chiếu xử lý giao hàng | Orders được xử lý như thế nào và hệ thống bên ngoài nào nhận diện quá trình đó |
| Câu trả lời checkout và ghi chú | Chỉ dẫn hoặc khai báo thuộc riêng giao dịch và cần nằm cùng Orders |
| Mã định danh bên ngoài | Khóa đối chiếu với ERP, kế toán, xử lý giao hàng, marketplace hoặc CRM |
Lịch sử đơn hàng phải tiếp tục đọc được ngay cả khi Products hiện tại đã thay đổi, option bị ngừng sử dụng hoặc hệ thống tích hợp cũ không còn tồn tại. Vai trò của dữ liệu này là ghi lại hoạt động thương mại đã xảy ra, không phải làm mẫu cấu hình checkout tương lai.
URL SEO, Extra Pages, Blog Posts và dữ liệu nội dung
Nội dung storefront là một nguồn khác biệt mô hình dữ liệu đáng kể. Shift4Shop có thể bao gồm trang Products, trang Categories, Extra Pages, Blog Posts, SEO metadata, cấu trúc navigation, Reviews, Hỏi đáp về Products và những bản ghi nội dung khác. Cửa hàng nguồn có thể lưu thông tin tương tự trong CMS Pages, Blog Posts, page builder, ứng dụng, static files, theme sections hoặc custom templates.
Kế hoạch chuyển đổi nên phân loại nội dung theo chức năng. Một số trang cần thiết để duy trì SEO. Một số giúp Customers hiểu Products. Một số phục vụ chính sách, compliance, niềm tin hoặc giải thích thương hiệu. Một số đã lỗi thời và không nên được tái tạo. Coi mọi nội dung quan trọng như nhau tạo thêm công việc không cần thiết; coi nội dung chỉ là phần trang trí lại tạo rủi ro khi ra mắt.
| Bản ghi nội dung | Câu hỏi cần làm rõ |
|---|---|
| URL Products | URL nào cần giữ, redirects hoặc rà soát SEO? |
| URL Categories | Categories nào có giá trị tìm kiếm hoặc navigation quan trọng? |
| Extra Pages / CMS Pages | Trang nào hỗ trợ niềm tin, chính sách, chuyển đổi hoặc giáo dục Customers? |
| Blog Posts | Bài nào mang lưu lượng truy cập tự nhiên, internal links hoặc giúp người mua tìm Products? |
| Reviews và Hỏi đáp về Products | Bản ghi nào hỗ trợ niềm tin và giúp trang Products tiếp tục có giá trị? |
| Media nhúng | File, script, form hoặc thành phần layout nào cần xây dựng lại thủ công hoặc đánh giá riêng tại Nền tảng đích? |
Khi chuyển nội dung, cần giữ đúng ý nghĩa storefront còn giá trị. Page title và nội dung chính có thể thuộc bản ghi nội dung, trong khi form nhúng, widget của ứng dụng, layout theme, vị trí menu và URL cũ thuộc những quan hệ trình bày hoặc tích hợp riêng.
Hệ thống tích hợp, trường tùy chỉnh và dữ liệu còn lại từ thời 3dcart
Nguồn gốc của Shift4Shop bao gồm các bản ghi và thuật ngữ được tạo từ thời nền tảng còn mang tên 3dcart. Nhãn cũ có thể xuất hiện trong bản export, trường tùy chỉnh, templates, hệ thống tích hợp, ghi chú nhân viên hoặc mapping với hệ thống bên ngoài. Tuổi của một nhãn không quyết định giá trị đã lỗi thời hay chưa; điều quyết định là hệ thống hiện đang sở hữu và cách doanh nghiệp còn sử dụng dữ liệu đó.
Các hệ thống bên ngoài có thể kết nối Products, Customers và Orders trong Shift4Shop với ERP, CRM, kế toán, xử lý giao hàng, marketplace, Reviews, email, thuế hoặc analytics. Một trường tùy chỉnh hiển thị trong cửa hàng có thể là nơi duy nhất lưu mã định danh mà hệ thống bên ngoài sử dụng. Thiết lập tích hợp, API credential hoặc webhook subscription là cấu hình; trong khi mã Products hoặc Orders được trao đổi qua kết nối lại là dữ liệu.
| Bản ghi tại nguồn | Quyết định về quyền sở hữu |
|---|---|
| Trường gốc của Shift4Shop | Giữ cùng bản ghi Products, Customers, Orders, Categories hoặc nội dung đang sở hữu giá trị đó. |
| trường bổ sung của Products | Tách nội dung mô tả trên storefront khỏi metadata chỉ dùng cho hệ thống tích hợp. |
| Trường bổ sung của Customers | Xác định đây là dữ liệu người mua lâu dài, quy tắc nhóm hay khóa của hệ thống bên ngoài. |
| Nhãn cũ từ 3dcart | Truy vết trường thực tế và quy trình đang dùng trước khi đổi tên, giữ lại hoặc loại bỏ. |
| Giá trị do ứng dụng tạo | Xác định ứng dụng, bản ghi cha và nơi sở hữu trên Nền tảng đích; không giả định giá trị có trong core export. |
| ID từ ERP/CRM/hệ thống xử lý giao hàng | Giữ ở cấp Products, Customers, Orders, shipment hoặc company mà hệ thống bên ngoài nhận diện. |
| API user, token hoặc cấu hình webhook | Tạo lại an toàn dưới dạng cấu hình Nền tảng đích thay vì chuyển như dữ liệu Customers hoặc nội dung. |
Bản đồ lineage có chất lượng cần kết nối tên trường cũ, ý nghĩa kinh doanh hiện tại, hệ thống có thẩm quyền, bản ghi cha và vị trí trên Nền tảng đích. Cách làm này vừa tránh mất những khóa tích hợp vẫn đang hoạt động, vừa tránh giữ lại phần dư thừa từ các tùy chỉnh đã ngừng sử dụng.
Kết luận
Khác biệt mô hình dữ liệu của Shift4Shop quan trọng nhất ở những nơi bản ghi tưởng như thông thường lại mang ý nghĩa thương mại. Options của Products có thể kiểm soát giá và tồn kho. Categories có thể ảnh hưởng navigation và SEO. Nhóm Customers có thể quyết định cách phục vụ người mua. Promotions có thể ảnh hưởng doanh thu. Orders lưu lại lịch sử vận hành. Nội dung duy trì khả năng tìm thấy Products và niềm tin. Các hệ thống tích hợp có thể sở hữu những trường không thuộc dữ liệu gốc của cửa hàng.
Vì vậy, một dự án Shift4Shop có chất lượng cần chuyển dữ liệu theo chức năng và quan hệ, không chỉ theo tên trường. Kết quả tại Nền tảng đích phải giữ những ý nghĩa giúp người mua mua hàng, nhân viên quản lý cửa hàng và doanh nghiệp tiếp tục vận hành sau khi ra mắt.
Câu hỏi thường gặp
Tại sao options của Products lại quan trọng trong dự án chuyển sang Shift4Shop?
Options có thể ảnh hưởng đến lựa chọn của người mua, giá, tồn kho, cách xử lý giao hàng và mức độ rõ ràng của trang Products. Chúng cần được đánh giá tách biệt khỏi thông số mô tả vì không phải mọi attribute tại nguồn đều nên trở thành lựa chọn có thể mua.
Categories trong Shift4Shop có giống Categories hoặc collections ở cửa hàng nguồn không?
Không phải lúc nào cũng giống. Cửa hàng nguồn có thể sử dụng Categories, collections, tags, menus hoặc nhóm động theo cách khác nhau. Khi lập kế hoạch cho Shift4Shop, cần giữ ý nghĩa hữu ích đối với browsing và SEO thay vì sao chép cơ học mọi nhóm tại nguồn.
Nhóm Customers có nên luôn được chuyển nguyên trạng không?
Mỗi nhóm Customers cần được đánh giá theo mục đích. Nhóm chỉ dùng cho marketing khác với nhóm kiểm soát giá bán sỉ, miễn thuế, mức độ hiển thị hoặc cách B2B Orders được tạo.
Lịch sử đơn hàng có thể tái tạo quy trình vận hành cũ không?
Lịch sử đơn hàng nên giữ đủ ngữ cảnh cho hỗ trợ và vận hành, nhưng không tự động tái tạo payment, quy trình xử lý giao hàng, refund hoặc quy trình tích hợp cũ trong Shift4Shop.
Khi nào các trường tùy chỉnh cần lập bản đồ quyền sở hữu riêng?
Cần phân tích riêng khi giá trị do ứng dụng tạo, mã định danh bên ngoài hoặc bản ghi tích hợp không thực sự thuộc trường dữ liệu thông thường của Products, Customers, Orders hoặc nội dung.
Các trường còn lại từ thời 3dcart nên nằm ở đâu trong mô hình Nền tảng đích?
Hãy phân loại theo cách doanh nghiệp còn sử dụng thay vì theo tuổi hoặc tên trường. Trường vẫn điều khiển hiển thị catalog, cách phục vụ Customers, xử lý giao hàng, báo cáo hoặc hệ thống tích hợp cần vị trí đích rõ ràng. Các trường tùy chỉnh đã bỏ và dữ liệu dư thừa của hệ thống tích hợp cũ nên được ghi nhận rồi loại khỏi phạm vi thay vì tự động sao chép.