Tích hợp

Thường ngân hàng quyết định. Host-to-host SFTP là kênh được cung cấp rộng rãi nhất cho tệp thanh toán doanh nghiệp. EBICS phổ biến với ngân hàng ở Đức, Pháp và các nước lân cận. API ngân hàng phù hợp với số dư thời gian thực và thanh toán tức thời khi ngân hàng cung cấp. Nhiều công ty dùng nhiều hơn một kênh, và lớp tích hợp giúp ERP không phải xử lý khác biệt đó.

Đọc thêm: Tệp thanh toán từ ERP tới ngân hàng và đối soátLiên kết tới câu hỏi này

Khi ngân hàng cung cấp cả hai, camt.053 mang dữ liệu chuyển tiền có cấu trúc và phong phú hơn, giúp đối soát tự động đáng tin hơn. MT940 vẫn được dùng rộng rãi và hoạt động tốt trong nhiều trường hợp. Chúng tôi có thể nhận cả hai, chuyển chúng về cùng một mô hình nội bộ, và chuyển từng ngân hàng từ MT940 sang camt.053 khi phù hợp với bạn và ngân hàng.

Đọc thêm: Tệp thanh toán từ ERP tới ngân hàng và đối soátLiên kết tới câu hỏi này

Thường là theo sự kiện gần thời gian thực, vì số liệu tồn kho và doanh số khi đó là hiện hành trong ngày. Một số ERP hoặc giấy phép khiến việc ghi dày đặc tốn kém, nên lớp tích hợp cũng có thể gộp sự kiện thành tổng hợp theo cửa hàng và kỳ. Chúng tôi chọn cùng bạn dựa trên việc quyết định nào cần dữ liệu hiện hành và ERP xử lý tốt điều gì.

Đọc thêm: Đồng bộ doanh số, tồn kho và giá giữa POS và ERPLiên kết tới câu hỏi này

Thiết kế làm việc với mọi POS có thể xuất giao dịch qua API, sự kiện hoặc tệp, và với các ERP như SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central và Odoo. Chúng tôi xác nhận giao diện của POS và ERP cụ thể của bạn ngay từ đầu. Việc nêu tên một sản phẩm không có nghĩa là có quan hệ đối tác với nhà cung cấp của nó.

Đọc thêm: Đồng bộ doanh số, tồn kho và giá giữa POS và ERPLiên kết tới câu hỏi này

Tổ chức thanh toán thẻ là ngân hàng hoặc tổ chức được cấp phép xử lý thanh toán thẻ cho bạn và chi trả tiền. Cổng thanh toán là dịch vụ kỹ thuật đứng trước đó, nhận yêu cầu từ thiết bị thanh toán và trang thanh toán, token hóa thẻ và định tuyến yêu cầu. Một số nhà cung cấp đảm nhận cả hai. Thiết kế hoạt động trong cả hai trường hợp và giữ rõ vai trò của hai bên.

Đọc thêm: Thanh toán thẻLiên kết tới câu hỏi này

Không. ISO 8583 định nghĩa một cấu trúc, và mỗi tổ chức thanh toán thẻ hoặc mạng lưới thẻ công bố đặc tả riêng về trường, loại thông điệp và mã. Vì vậy chúng tôi xây từ đặc tả của tổ chức thanh toán thẻ và chạy các bài kiểm thử chứng nhận của họ. Một API cổng thanh toán đứng trước tổ chức thanh toán thẻ che đi những khác biệt này, thường đơn giản hơn cho nhà bán lẻ.

Đọc thêm: Thanh toán thẻLiên kết tới câu hỏi này

Bên tổng hợp cho bạn nhiều ngân hàng qua một API và xử lý khác biệt của từng ngân hàng, với chi phí theo lệnh gọi hoặc theo kết nối. Kết nối trực tiếp cho nhiều quyền kiểm soát hơn và có thể hợp với một số ít ngân hàng quan trọng. Nhiều sản phẩm bắt đầu với bên tổng hợp và thêm kết nối trực tiếp sau. Chúng tôi so sánh các phương án theo ngân hàng và quốc gia bạn cần.

Đọc thêm: API ngân hàng mởLiên kết tới câu hỏi này

Phạm vi phụ thuộc quy định của khu vực và API của ngân hàng. Liên minh châu Âu và Vương quốc Anh có phạm vi rộng theo PSD2 và Tiêu chuẩn Ngân hàng mở Vương quốc Anh. Ở các khu vực khác, phạm vi không đồng đều, và các bên tổng hợp lấp một phần khoảng trống. Chúng tôi kiểm tra phạm vi cho những ngân hàng khách hàng của bạn dùng trước khi bạn cam kết một thiết kế.

Đọc thêm: API ngân hàng mởLiên kết tới câu hỏi này

Không, với phần lớn công việc ngân quỹ của doanh nghiệp. Kênh host-to-host xử lý tệp thanh toán khối lượng lớn và sao kê đầy đủ cho tài khoản của chính bạn. Ngân hàng mở hợp với sản phẩm hướng khách hàng, số dư thời gian thực và thanh toán đơn lẻ. Nhiều doanh nghiệp dùng cả hai: host-to-host cho lô thanh toán của mình và ngân hàng mở cho khách hàng của họ.

Đọc thêm: API ngân hàng mởLiên kết tới câu hỏi này

Mọi dịch vụ có API hoặc giao diện tệp được ghi tài liệu. Ví dụ điển hình là nền tảng CRM, hãng vận chuyển và nhà cung cấp logistics, sàn thương mại, nền tảng hóa đơn điện tử và thuế, tính lương, nhà cung cấp KYC và danh tính, và đối tác thương mại trao đổi chứng từ EDI qua AS2. Chúng tôi xem xét API, giới hạn và môi trường thử của từng đối tác trước khi cam kết một kế hoạch.

Đọc thêm: Kết nối API giữa ERP và bên thứ baLiên kết tới câu hỏi này

Khi đã có nhiều đối tác kết nối với một ERP, một nền tảng như MuleSoft, Boomi hay Azure Logic Apps, hoặc một bộ dịch vụ tùy chỉnh xây trên hàng đợi thông điệp, giữ ánh xạ, thử lại và giám sát ở một nơi. Với một hoặc hai đối tác, kết nối trực tiếp có thể đủ. Chúng tôi trình bày các đánh đổi, gồm chi phí giấy phép, cho trường hợp của bạn.

Đọc thêm: Kết nối API giữa ERP và bên thứ baLiên kết tới câu hỏi này

Về ERP: SAP ECC, S/4HANA và BTP, Oracle Fusion Cloud ERP và NetSuite, Microsoft Dynamics 365, Odoo và Sage. Về quy trình và CRM: ServiceNow, Salesforce và Microsoft Power Platform. Chúng tôi cũng làm việc với hệ thống tùy chỉnh và cũ hơn. Nêu tên một sản phẩm không có nghĩa là quan hệ đối tác với nhà cung cấp của nó.

Đọc thêm: Triển khai và đồng bộ ERP, CRMLiên kết tới câu hỏi này

Có. Chúng tôi kiểm kê mọi giao diện trên ECC, quyết định giữ, xây lại hay loại bỏ, và chuyển từng giao diện sang S/4HANA hoặc BTP kèm kiểm thử. Các luồng chuyển từng cái một, để doanh nghiệp không phụ thuộc vào một cuối tuần chuyển đổi duy nhất.

Đọc thêm: Triển khai và đồng bộ ERP, CRMLiên kết tới câu hỏi này

Không phải lúc nào cũng cần. Vài luồng ổn định giữa hai hệ thống có thể gọi API trực tiếp. Khi nhiều hệ thống trao đổi dữ liệu, hoặc bạn cần ánh xạ, hàng đợi và giám sát ở một nơi, phần mềm trung gian thường tự hoàn vốn. Nếu bạn đã có phần mềm trung gian, chúng tôi xây trên nền đó.

Đọc thêm: Triển khai và đồng bộ ERP, CRMLiên kết tới câu hỏi này

Chọn CRM phù hợp quy trình, tích hợp và người dùng của bạn. Chúng tôi so sánh các lựa chọn theo yêu cầu, giấy phép hiện có và hệ thống CRM phải kết nối tới, và trình bày đánh đổi bằng văn bản. Nếu bạn đã có CRM, chúng tôi rà soát cấu hình, dữ liệu và tích hợp trước, vì vấn đề ở đó phổ biến hơn giới hạn của sản phẩm.

Đọc thêm: Triển khai và đồng bộ ERP, CRMLiên kết tới câu hỏi này

Quá nhiều là khi nâng cấp trở nên rủi ro và mọi thay đổi đều cần lập trình viên. Chúng tôi cấu hình những gì nền tảng có trước, và chỉ viết mã tùy chỉnh khi quy trình của bạn cần và đáng để duy trì. Mỗi tính năng tùy chỉnh đều có tài liệu và kiểm thử, để nâng cấp vẫn quản lý được.

Đọc thêm: Triển khai và đồng bộ ERP, CRMLiên kết tới câu hỏi này

Giai đoạn 2, tức giai đoạn tích hợp, yêu cầu hệ thống của người nộp thuế kết nối với nền tảng FATOORA của ZATCA. Hóa đơn thuế tiêu chuẩn được ZATCA phê duyệt trước khi đến người mua, còn hóa đơn rút gọn được báo cáo ngay sau đó. Mỗi hóa đơn mang một con dấu mật mã và một mã QR, nên ERP hoặc POS phải tạo được chúng đúng định dạng yêu cầu.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

PINT-AE là đặc tả của UAE cho định dạng hóa đơn quốc tế PEPPOL, dùng trong chương trình hóa đơn điện tử của UAE. Hóa đơn được trao đổi theo định dạng có cấu trúc này qua các nhà cung cấp dịch vụ được công nhận và được báo cáo cho Cơ quan Thuế Liên bang, cơ quan dùng nền tảng EmaraTax để quản lý thuế của UAE.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

Thuế GTGT trong thời đại số (ViDA) là gói của EU đưa hóa đơn kinh doanh xuyên biên giới sang hóa đơn điện tử có cấu trúc và báo cáo số. Gói này ảnh hưởng đến mọi doanh nghiệp xuất hóa đơn cho khách hàng EU hoặc có pháp nhân tại EU, bất kể trụ sở ở đâu.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

Hộ chiếu sản phẩm số (DPP) là bản ghi của EU về vật liệu, xuất xứ, khả năng sửa chữa và tái chế của sản phẩm, được chia sẻ qua vật mang dữ liệu như mã QR. Hộ chiếu được áp dụng dần theo từng nhóm sản phẩm. Hộ chiếu dựa vào dữ liệu chuỗi cung ứng thường nằm trong ERP và hệ thống sản xuất.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

Thường thì tiện ích đó là điểm khởi đầu đúng, và chúng tôi cấu hình và mở rộng tiện ích đó thay vì xây thêm một lớp bao quanh. Phần việc còn lại thường là dữ liệu: loại hóa đơn, mã thuế, dữ liệu chủ và ngoại lệ mà tiện ích không bao phủ. POS và các hệ thống khác có phát hành hóa đơn cũng cần được kết nối.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

Có. Chúng tôi xây một lớp tích hợp với một bộ kết nối cho mỗi yêu cầu. ERP tạo một hóa đơn, còn lớp tích hợp định dạng, ký và gửi cho từng quốc gia. Thêm một quốc gia chỉ còn là việc cấu hình, ánh xạ và kiểm thử.

Đọc thêm: Hóa đơn điện tử, thuế và hộ chiếu sản phẩm sốLiên kết tới câu hỏi này

ISO 20022 là tiêu chuẩn quốc tế về thông điệp tài chính. Thông điệp XML của nó mang dữ liệu có cấu trúc, như họ tên đầy đủ, địa chỉ và chi tiết chuyển tiền, mà các định dạng SWIFT MT cũ không có. Ngân hàng và hệ thống thanh toán đã chuyển sang tiêu chuẩn này, nên tệp thanh toán và sao kê dựa trên tiêu chuẩn này đối soát tốt hơn và thường vượt qua kiểm tra tuân thủ hơn.

Đọc thêm: Ngân hàng, ngân quỹ và kết nối ISO 20022Liên kết tới câu hỏi này

Chúng tôi dùng pain.001 cho lệnh chi, pain.002 cho trạng thái, camt.052, camt.053 và camt.054 cho báo cáo tài khoản, và thông điệp pacs giữa các ngân hàng. Chúng tôi cũng đọc sao kê MT940 và MT942 mà nhiều ngân hàng vẫn gửi. Kênh truyền là host-to-host SFTP, EBICS, SWIFT hoặc API ngân hàng. Mỗi ngân hàng có biến thể riêng cho từng định dạng, nên chúng tôi xây dựa trên hướng dẫn triển khai của họ.

Đọc thêm: Ngân hàng, ngân quỹ và kết nối ISO 20022Liên kết tới câu hỏi này

SAP S/4HANA, Oracle Fusion Cloud ERP và NetSuite, Microsoft Dynamics 365, Odoo và Sage, cùng các hệ thống ngân quỹ và hệ thống tùy chỉnh. Nếu ERP có mô-đun giao tiếp ngân hàng riêng, chúng tôi cấu hình và mở rộng mô-đun đó thay vì xây thêm một lớp bao quanh.

Đọc thêm: Ngân hàng, ngân quỹ và kết nối ISO 20022Liên kết tới câu hỏi này

Có, nếu tổ chức thanh toán thẻ hoặc đơn vị xử lý hỗ trợ. ISO 8583 là một khuôn khổ chứ không phải một định dạng: mỗi tổ chức thanh toán thẻ công bố đặc tả riêng về trường và loại thông điệp. Chúng tôi xây dựa trên đặc tả đó, xử lý ủy quyền, đảo giao dịch và thông điệp thông báo, và kiểm thử mọi mã phản hồi.

Đọc thêm: Thanh toán, thương mại tác nhân (AP2) và POSLiên kết tới câu hỏi này

Giao thức thanh toán tác nhân (AP2) là giao thức mở cho thanh toán do tác nhân AI thực hiện. Mỗi giao dịch mang ủy quyền đã ký cho thấy khách hàng đã chấp thuận gì, để người bán, ngân hàng phát hành và tổ chức thanh toán thẻ có thể tin cậy và kiểm toán. Nếu tác nhân AI có khả năng mua sắm với bạn, chúng tôi có thể chuẩn bị trang thanh toán của bạn sẵn sàng cho AP2 song song với các luồng hiện tại.

Đọc thêm: Thanh toán, thương mại tác nhân (AP2) và POSLiên kết tới câu hỏi này

Có, với SoftPOS. Thẻ không tiếp xúc và ví điện tử được nhận trên điện thoại hoặc máy tính bảng được hỗ trợ qua ứng dụng thanh toán đã chứng nhận của tổ chức thanh toán thẻ hoặc nhà cung cấp. Chúng tôi tích hợp ứng dụng đó với luồng POS, bán hàng và quyết toán như mọi thiết bị thanh toán khác.

Đọc thêm: Thanh toán, thương mại tác nhân (AP2) và POSLiên kết tới câu hỏi này

Cửa hàng vẫn bán tiếp. Giao dịch được lưu cục bộ và gửi lên ERP khi kết nối trở lại, mỗi giao dịch có mã định danh duy nhất để không bị hạch toán hai lần. Việc thanh toán thẻ có thể tiếp tục ngoại tuyến hay không phụ thuộc quy tắc của tổ chức thanh toán thẻ và mức chấp nhận rủi ro của bạn, và chúng tôi thiết kế điều đó cùng bạn.

Đọc thêm: Thanh toán, thương mại tác nhân (AP2) và POSLiên kết tới câu hỏi này

Điều đó phụ thuộc số kết nối bạn có và ai sẽ vận hành chúng. Nền tảng tích hợp như MuleSoft, Boomi hay Azure Logic Apps cho bạn bộ kết nối, ánh xạ và giám sát sẵn có ở một nơi, với chi phí giấy phép. Dịch vụ tùy chỉnh cho bạn toàn quyền kiểm soát và không mất phí giấy phép, nhưng nhiều mã phải bảo trì hơn. Chúng tôi so sánh cả hai cho trường hợp của bạn.

Đọc thêm: Dịch vụ tích hợp phần mềm trung gian và APILiên kết tới câu hỏi này

Bus dịch vụ doanh nghiệp định tuyến và biến đổi thông điệp qua một trung tâm. Lưới sự kiện phân phối sự kiện qua mạng các broker kết nối, để hệ thống ở các đám mây và địa điểm khác nhau phát và đăng ký trực tiếp. Nhiều hệ thống chạy cả hai trong lúc chuyển từ cái này sang cái kia.

Đọc thêm: Dịch vụ tích hợp phần mềm trung gian và APILiên kết tới câu hỏi này

Chúng tôi thiết kế theo giới hạn đã công bố của từng đối tác. Chúng tôi gộp yêu cầu khi API cho phép, lưu đệm dữ liệu ít thay đổi, dàn đều tác vụ theo lịch và giãn nhịp gửi khi gần chạm giới hạn. Giám sát cho thấy mỗi luồng chạy sát giới hạn đến đâu.

Đọc thêm: Dịch vụ tích hợp phần mềm trung gian và APILiên kết tới câu hỏi này