Tại sao tích hợp AutoCount tạo ra bản ghi sai khi đồng bộ hóa hoạt động
Đồng bộ hóa có thể thành công nhưng bản ghi vẫn có thể sai.
Đó là phần mà nhiều doanh nghiệp bỏ lỡ.
Đầu nối chạy.
Không có thông báo lỗi xuất hiện.
Dữ liệu đạt AutoCount.
Nhưng hóa đơn bị trùng lặp.
Mục UOM sai.
Mã khách hàng không khớp.
Quá trình phân phối chỉ diễn ra một phần nhưng bản ghi đã đồng bộ hóa có vẻ đã hoàn tất.
Phiên bản được phê duyệt đã thay đổi sau lần đồng bộ hóa đầu tiên.
Vấn đề có thể không phải là đầu nối.
Sự cố có thể là do luồng công việc nguồn cung cấp AutoCount.
# Tại sao lỗi tích hợp AutoCount xảy ra ngay cả khi đồng bộ hóa thành công
Tích hợp di chuyển các bản ghi dựa trên các quy tắc.
Nó không đưa ra quyết định kinh doanh trừ khi những quy tắc đó được thiết kế trong đó.
Để biết chế độ xem cấp độ dịch vụ của tác phẩm này, hãy xem Tích hợp AutoCount.
Thiết lập AutoCount có thể kết nối thông qua các tuyến khác nhau, chẳng hạn như API, SDK hoặc tập hợp, AOTG REST, nhập, phần mềm trung gian, plugin hoặc các phương thức kết nối khác. Lộ trình chính xác phụ thuộc vào phiên bản, thiết lập và thiết kế dự án.
Nhưng mọi tuyến đường vẫn cần có quy tắc nguồn rõ ràng. Nếu dự án kết nối một số hệ thống, tích hợp hệ thống API vẫn phải bắt đầu với các quy tắc sẵn sàng cho doanh nghiệp.
Nếu hệ thống bên ngoài gửi dữ liệu không rõ ràng, việc tích hợp có thể di chuyển dữ liệu không rõ ràng một cách chính xác.
Đó là lý do tại sao lỗi tích hợp AutoCount thường là vấn đề về mức độ sẵn sàng của quy trình làm việc.
# Khoảng cách quy tắc 1: Trạng thái
Câu hỏi đầu tiên rất đơn giản:
Trạng thái nào được phép đồng bộ hóa?
Ví dụ:
- dự thảo;
- đang chờ phê duyệt;
- tán thành;
- sẵn sàng để chọn;
- giao một phần;
- đã giao hàng;
- trở lại;
- bị hủy bỏ;
- sẵn sàng thanh toán;
- ngoại lệ.
Nếu quá trình tích hợp đồng bộ hóa quá sớm, AutoCount có thể nhận được các bản ghi vẫn đang thay đổi.
Nếu đồng bộ hóa quá muộn, các tài khoản có thể đợi các bản ghi đã hoàn tất thao tác.
Nếu tên trạng thái không rõ ràng, những người dùng khác nhau có thể xử lý cùng một bản ghi một cách khác nhau.
Quy trình làm việc nguồn phải xác định trạng thái có nghĩa là "sẵn sàng cho AutoCount".
# Khoảng trống quy tắc 2: Lập bản đồ và UOM
Lập bản đồ hiện trường không chỉ là một bài tập kỹ thuật.
Nó quyết định từng phần dữ liệu nguồn sẽ trở thành gì trong AutoCount.
Rủi ro lập bản đồ phổ biến bao gồm:
- mã khách hàng không khớp;
- mã nhà cung cấp không khớp;
- mã mặt hàng không khớp;
- chi nhánh hoặc địa điểm không phù hợp;
- UOM không khớp;
- mã số thuế không khớp;
- mức giá không phù hợp;
- ngày của tài liệu không khớp;
- nhân viên bán hàng hoặc mã dự án không khớp.
AutoCount có thể hỗ trợ thiết lập vật phẩm và chuyển đổi UOM tùy thuộc vào cấu hình. Nhưng hệ thống nguồn, thiết lập mục, tỷ lệ chuyển đổi và ánh xạ tích hợp phải thống nhất.
Nếu một hệ thống gửi thùng carton và một hệ thống khác gửi kiện hàng mong muốn, việc đồng bộ hóa có thể thành công nhưng số lượng có thể sai.
Nếu một hệ thống sử dụng tên chi nhánh và AutoCount yêu cầu mã vị trí, quá trình đồng bộ hóa có thể thành công nhưng kho hàng có thể di chuyển sai vị trí.
Đây không chỉ là sự cố API.
Đó là một vấn đề quy tắc dữ liệu.
# Khoảng cách quy tắc 3: Phê duyệt và lập phiên bản
Một số bản ghi thay đổi sau khi chúng được tạo lần đầu tiên.
Một khách hàng thay đổi số lượng.
Bán hàng thay đổi giá.
Kho xác nhận giao hàng một phần.
Mua hàng thay đổi nhà cung cấp.
Ban quản lý phê duyệt một ngân sách khác.
Việc tích hợp phải biết phiên bản nào được phép đạt AutoCount.
Nếu bản ghi nháp được đồng bộ hóa trước, điều gì sẽ xảy ra khi phê duyệt thay đổi bản ghi đó?
Nếu bản ghi đã phê duyệt được chỉnh sửa sau, thì bản tích hợp có nên cập nhật AutoCount, tạo tài liệu mới, chặn thay đổi, đảo ngược bản ghi cũ hay gửi bản ghi đó để xem xét thủ công không?
Câu trả lời tùy thuộc vào loại tài liệu, thiết lập AutoCount và quy tắc kinh doanh.
Nhưng quy tắc phải tồn tại.
Không có nó, hệ thống nguồn và AutoCount sẽ dần dần kể những câu chuyện khác nhau.
# Khoảng cách quy tắc 4: Thời gian
Đồng bộ thời gian thực nghe có vẻ hấp dẫn.
Nhưng không phải mọi quy trình làm việc đều phải đồng bộ hóa theo thời gian thực.
Một số bản ghi sẽ được đồng bộ hóa ngay lập tức.
Một số chỉ nên đồng bộ hóa sau khi được phê duyệt.
Một số nên đồng bộ sau khi xác nhận kho.
Một số sẽ đồng bộ hóa hàng loạt sau khi kiểm tra hàng ngày.
Một số nên được giữ lại vì chúng là trường hợp ngoại lệ.
Ví dụ: Lệnh bán hàng có thể sẵn sàng sớm hơn Lệnh giao hàng. Lệnh giao hàng có thể sẵn sàng trước khi xuất hóa đơn. Yêu cầu mua hàng có thể chưa sẵn sàng cho PO cho đến khi quá trình phê duyệt hoàn tất.
Nếu thời gian sai, AutoCount có thể nhận được bản ghi trước khi doanh nghiệp sẵn sàng tin tưởng nó.
# Khoảng cách quy tắc 5: Ngoại lệ và trùng lặp
Quy tắc tích hợp quan trọng nhất có thể là những gì không nên đồng bộ hóa.
Tích hợp sản xuất nên xử lý các trường hợp ngoại lệ như:
| Ngoại lệ | Quy tắc cần thiết | Rủi ro nếu không xác định |
|---|---|---|
| khách hàng hoặc nhà cung cấp trùng lặp | quy tắc khớp và hợp nhất | tài khoản trùng lặp hoặc lão hóa sai |
| hóa đơn trùng lặp | quy tắc tham chiếu duy nhất | thanh toán gấp đôi hoặc đăng đôi |
| giao hàng một phần | quy tắc thanh toán và đồng bộ hóa một phần | sai số lượng trong kho hoặc hóa đơn |
| đơn hàng bị hủy | quy tắc đảo ngược, chặn hoặc xem xét | hồ sơ bị hủy vẫn hoạt động |
| đã thay đổi giá | quy tắc phê duyệt/phiên bản | số tiền hóa đơn sai |
| UOM không khớp | quy tắc thiết lập mục và chuyển đổi | sai số lượng tồn kho |
| đồng bộ hóa không thành công | thử lại và xem lại quy tắc | hồ sơ thất lạc không có chủ |
| chỉnh sửa thủ công sau khi đồng bộ hóa | quy tắc sở hữu | AutoCount và hệ thống nguồn khác nhau |
Nếu trường hợp ngoại lệ không được thiết kế, nhân viên sẽ khắc phục thủ công.
Sửa lỗi thủ công có thể hoạt động cho một trường hợp.
Chúng trở nên nguy hiểm khi chúng trở thành quá trình bình thường.
# Tích hợp nên có Khu vực nắm giữ
Đối với nhiều tích hợp quy trình công việc bên ngoài, kiến trúc an toàn hơn không phải là:
hệ thống nguồn gửi mọi thứ thẳng vào AutoCount.
Kiến trúc an toàn hơn là:
hệ thống nguồn tạo bản ghi, kiểm tra mức độ sẵn sàng của quy trình làm việc, quy tắc ngoại lệ giữ các bản ghi rủi ro, sau đó đồng bộ hóa bản ghi sạch vào AutoCount.
Khu vực lưu giữ này có thể là hàng đợi, màn hình đánh giá, trạng thái phê duyệt, nhật ký tích hợp hoặc bảng điều khiển ngoại lệ. Để biết ánh xạ dữ liệu dành riêng cho AutoCount và thiết kế API, hãy xem API và tích hợp dữ liệu.
Tên ít quan trọng hơn sự kiểm soát.
Trước khi bản ghi nhập AutoCount, doanh nghiệp nên biết:
- trạng thái đã sẵn sàng;
- khách hàng hoặc nhà cung cấp phù hợp;
- vật phẩm và UOM phù hợp;
- ngày lập tài liệu là chính xác;
- các bản sao bị chặn;
- ngoại lệ có chủ sở hữu;
- đồng bộ hóa không thành công có thể được xem xét.
# Điều này khác với lỗi nhập thủ công
Việc gõ lại thủ công tạo ra những rủi ro rõ ràng: lỗi đánh máy, thiếu trường, sai mã, nhập chậm. Nếu vấn đề trước mắt là việc nhập thủ công lặp lại, hãy bắt đầu bằng dừng nhập lại dữ liệu vào AutoCount.
Tích hợp loại bỏ một số rủi ro đó.
Nhưng nó tạo ra một rủi ro khác:
quy tắc sai có thể tạo ra hồ sơ sai trên quy mô lớn.
Nếu vấn đề của bạn chủ yếu là nhập lại dữ liệu PO, hãy đọc tại sao việc nhập PO thủ công vào AutoCount lại tạo ra lỗi ẩn.
Nếu vấn đề của bạn là các hệ thống được kết nối đang tạo sai bản ghi AutoCount ngay cả khi đồng bộ hóa chạy, hãy sửa quy trình tích hợp và quy trình làm việc nguồn.
# Điều này cũng khác với "Có thể kết nối AutoCount không?"
Nhiều doanh nghiệp vừa và nhỏ hỏi liệu AutoCount có thể kết nối với phần mềm khác hay không.
Câu trả lời thường là có, tùy thuộc vào phiên bản, thiết lập, lộ trình và yêu cầu.
Nhưng câu hỏi quan trọng hơn là:
Những gì nên được phép kết nối?
Nếu bạn vẫn đang quyết định tuyến kết nối, hãy đọc AutoCount có thể kết nối với phần mềm khác.
Nếu bạn đã gặp lỗi đồng bộ hóa, trước tiên hãy kiểm tra quy trình làm việc nguồn.
Câu hỏi thường gặp
# Tại sao tích hợp AutoCount tạo ra các bản ghi sai ngay cả khi đồng bộ hóa hoạt động?
Bởi vì trình kết nối có thể đang di chuyển dữ liệu nguồn một cách chính xác nhưng dữ liệu nguồn có thể chưa sẵn sàng. Các quy tắc về trạng thái, ánh xạ, phê duyệt, thời gian, ngoại lệ và trùng lặp phải rõ ràng trước khi đồng bộ hóa bản ghi.
# Đây có phải là sự cố AutoCount API không?
Không phải lúc nào cũng vậy. Các tuyến tích hợp AutoCount khác nhau tùy theo thiết lập, phiên bản và thiết kế dự án. Nhiều vấn đề về bản ghi sai xuất phát từ các quy tắc quy trình làm việc nguồn không rõ ràng chứ không phải do chính phương thức kết nối.
# Tại sao đồng bộ hóa AutoCount lại tạo ra hóa đơn hoặc hồ sơ trùng lặp?
Bản ghi trùng lặp có thể xảy ra khi các tham chiếu duy nhất, quy tắc khớp, logic thử lại, quy tắc cập nhật hoặc quyền sở hữu chỉnh sửa thủ công không được xác định rõ ràng trước khi tích hợp.
# Nên tích hợp AutoCount theo thời gian thực hay theo đợt?
Nó phụ thuộc vào quy trình làm việc. Đồng bộ hóa thời gian thực rất hữu ích khi các bản ghi ổn định và sẵn sàng. Đồng bộ hóa hàng loạt hoặc dựa trên đánh giá có thể an toàn hơn khi hồ sơ cần phê duyệt, kiểm tra, thực hiện một phần hoặc xử lý ngoại lệ.
# Cần khắc phục điều gì trước khi tích hợp AutoCount?
Khắc phục tình trạng sẵn sàng, ánh xạ trường, chuyển đổi UOM, phê duyệt/phiên bản, kích hoạt thời gian, xử lý ngoại lệ, ngăn ngừa trùng lặp, quy tắc thử lại và quyền sở hữu kiểm tra.
# Phải làm gì tiếp theo
Nếu tích hợp AutoCount tạo bản ghi sai, đừng chỉ kiểm tra xem trình kết nối có trực tuyến hay không.
Kiểm tra quy trình làm việc nguồn.
Chọn một bản ghi sai và theo dõi:
- nó có trạng thái gì trước khi đồng bộ hóa;
- ai đã phê duyệt nó;
- trường nào được ánh xạ vào AutoCount;
- liệu thiết lập UOM và vật phẩm có khớp hay không;
- liệu nó có bị thay đổi sau khi đồng bộ hóa hay không;
- liệu có tồn tại quy tắc trùng lặp hay không;
- liệu hàng đợi ngoại lệ có phát hiện được sự cố hay không.
Dấu vết đó sẽ cho biết vấn đề là do kỹ thuật, quy trình làm việc hay cả hai.
Result Marketing giúp các doanh nghiệp vừa và nhỏ lập bản đồ mức độ sẵn sàng của quy trình làm việc nguồn trước khi kết nối các hệ thống bên ngoài với AutoCount.