Bạn vừa build xong app đầu tiên trên Cleeksy? Đừng để thành quả của mình nằm im mà hãy chia sẻ với cộng đồng nhé! Mình muốn nghe về hành trình của bạn:
App đầu tiên bạn build là gì?
Tính năng nào bạn thấy hữu ích nhất trong quá trình build?
Tính năng nào bạn thấy còn chưa quen tay?
Drop kết quả của bạn vào đây và kể cho cộng đồng nghe nhé, dù app còn đơn giản cũng không sao, first app luôn đáng được chia sẻ! 
App đầu tiên mà em build là Purchase Request để quản lý việc tạo và duyệt các yêu cầu mua sắm trong nội bộ doanh nghiệp. Dưới đây là một số hình ảnh về app:
Workflow bắt đầu từ việc tạo 1 yêu cầu mới (status là Draft để requester có thể thoải mái chỉnh sửa các field). Ở bước chuyển trạng thái “gửi yêu cầu mua”, request sẽ được tự động chuyển sang trạng thái pending approval và khóa các field lại. Tới bước duyệt mua, approver có hai lựa chọn đồng ý hoặc từ chối. Ở luồng đồng ý, sẽ thông báo việc cập nhật trạng thái request ở các bước sau cho người thu mua để thực hiện mua sắm và đóng request. Ở luồng từ chối, approver cần nhập lý do từ chối vào một field là cancel reason sau đó mới có thể từ chối (lúc này request đã có trạng thái rejected). Tiếp theo, requester sẽ được thông báo về request bị từ chối và họ có 2 lựa chọn là gửi lại yêu cầu hoặc xác nhận. Luồng gửi lại yêu cầu sẽ quay ngược lại từ bước gửi yêu cầu mua, trong khi luồng xác nhận sẽ xác nhận đóng request.
Một số tính năng hữu ích:
Tính năng Quy trình (Workflow) và Tự động hóa: Quy trình cho phép ta thiết lập luồng hoạt động của app theo từng bước nhỏ tương ứng với từng bước trong quy trình làm việc thực tế của một nghiệp vụ hoặc value stream (chuỗi đầu cuối). Trong khi đó, tự động hóa cho phép ta cập nhật dữ liệu ở các field trong record, khóa field, thêm mới vào record với những điều kiện cho trước. Hai tính năng này có thể kết hợp với nhau giúp tự động cập nhật lại các field cần thay đổi qua các bước (ví dụ như cập nhật status qua các bước) hoặc khóa các trường thông tin tại điều kiện xác định (khóa không cho sửa thông tin khi đã gửi yêu cầu cho approver để tránh bị sửa khi người approver đang duyệt).
Ngoài ra, kiểu dữ liệu Tham chiếu một chiều kết hợp cùng bảng dữ liệu cũng giúp đổ dữ liệu tự động khi chọn được tham chiếu chính xác từ các Master data như App quản lý vật tư, nhà cung cấp,… giúp tránh phải nhập tay thủ công quá nhiều.
Tính năng đang gặp khó khăn:
Mặc dù đã đọc qua tài liệu về tính năng tham chiếu hai chiều và nắm được khái niệm cơ bản, cũng như điều kiện cần để tạo tham chiếu hai chiều là 1 tham chiếu 1 chiều có trước. Tuy nhiên do chưa thực hành nhiều với tính năng này mà chủ yếu là sử dụng tham chiếu 1 chiều nên em cũng chưa nắm rõ được tham chiếu 2 chiều thường dùng trong những trường hợp nào? Em rất mong nhận được góp ý từ anh/chị về các trường hợp thường áp dụng và các lưu ý về lỗi thường mắc phải của người mới khi sử dụng tham chiếu 2 chiều.
Cảm ơn anh/chị đã dành thời gian đọc thông tin chia sẻ của em.
App “Yêu cầu mua hàng” là ứng dụng dùng để quản lý quá trình tạo và phê duyệt các yêu cầu mua hàng trong doanh nghiệp. Người dùng có thể tạo mới yêu cầu mua hàng bằng cách nhập các thông tin như tiêu đề, phòng ban, người yêu cầu, mô tả và danh sách hàng hóa cần mua thông qua bảng Chi tiết mua hàng. Hệ thống hỗ trợ tính tổng tiền tự động bằng Rollup dựa trên số lượng và đơn giá của từng mặt hàng. Sau khi hoàn tất, yêu cầu sẽ được gửi vào quy trình phê duyệt với các trạng thái như Draft, Pending Approval, Approved, Rejected và Closed nhằm theo dõi tiến độ xử lý. Khi yêu cầu được phê duyệt, dữ liệu sẽ được dùng để kết nối sang app xử lý mua hàng phục vụ cho bộ phận Procurement tiếp tục xử lý nghiệp vụ mua sắm.
Quy trình hoạt động của app bắt đầu khi người dùng tạo yêu cầu mua hàng ở trạng thái Draft và nhập các thông tin cần thiết như tiêu đề, phòng ban, danh sách hàng hóa và tổng tiền. Sau khi gửi yêu cầu, trạng thái chuyển sang Pending Approval để Approver xem xét phê duyệt hoặc từ chối. Nếu được phê duyệt, dữ liệu sẽ được kết nối sang app Procurement Execution để bộ phận Procurement tiếp tục xử lý mua hàng. Request sau đó sẽ trải qua các trạng thái In Procurement, Completed và cuối cùng là Closed để kết thúc quy trình. Nếu bị từ chối, request sẽ chuyển sang Rejected và được đóng lại để lưu lịch sử xử lý.
Ưu điểm:
Có workflow phê duyệt rõ ràng, dễ theo dõi trạng thái xử lý.
Dữ liệu liên kết giữa các app bằng Data Connection giúp tránh nhập liệu trùng lặp.
Hỗ trợ quản lý chi tiết hàng hóa bằng Sub-entity và tính tổng tiền tự động bằng Rollup.
Có thể mở rộng và tích hợp thêm các app khác như Nhà cung cấp hoặc Hàng hóa.
Nhược điểm:
Quy trình hiện tại còn đơn giản, chưa hỗ trợ nhiều cấp phê duyệt.
Một số dữ liệu vẫn nhập thủ công nên dễ sai lệch.
Khi thay đổi cấu trúc field có thể ảnh hưởng đến Data Connection và Lookup.
Chưa tích hợp sâu với các nghiệp vụ như kho hoặc kế toán.
Chào anh chị và các bạn, đây là lần đầu tiên mình tiếp cận tới việc build app trên một nền tảng low-code, no-code như Cleeksy. Và để bắt đầu build được một chiếc app hay nhiều chiếc app ưng ý thì mình có một lộ trình của bản thân như sau:
App 1 (Yêu cầu mua hàng - PR): Entity là “Phiếu yêu cầu”, quyền sở hữu (Ownership) thuộc về Requester (Người tạo yêu cầu).
App 2 (Đơn hàng - PO): Entity là “Đơn hàng”, quyền sở hữu thuộc về Buyer (Nhân viên mua hàng).
2. Song song với việc tạo Field các app như vậy mình học thêm về Data Connection để hiểu được nguyên lý kết nối, chuyển giao dữ liệu giữa các App. Hơn nữa, mình cũng sẽ tạo thêm một vài App chứa Master Data để học thêm những tính năng khác một cách thuần thục hơn như Ánh xạ dữ liệu, Tìm giá trị từ Master Data để đổ qua các dòng ghi của mỗi App.
Ngoài ra, mình đã sử dụng Sub-Entity để cho mỗi dòng yêu cầu mua hàng có thể có chứa dữ liệu của nhiều mặt hàng tùy theo số lượng, giá tiền đúng với nhu cầu và Budget dự kiến của doanh nghiệp.
3. Từ việc tạo các field và setup tham chiếu, ánh xạ vậy mình sẽ tiếp tục check về các giao diện, biểu mẫu nhập liệu cho mỗi record.
4. Tiếp đến mình sẽ bắt đầu thiết kế quy trình luồng phê duyệt và tự động theo như outline đã vạch ra:
Ở đây luồng trạng thái của mình như sau:
Từng bước mình sẽ set điều kiện để có thể tự động chuyển trạng thái và tạo các cấp phê duyệt yêu cầu mua, từ Draft người yêu cầu sẽ có quyền chỉnh sửa tất cả các trường và Sau khi đến Pending thì họ chỉ được xem và có 2 cấp phê duyệt là Ngân sách và Nhu cầu hợp lý. Tiếp đến bước Approval sẽ cho bắt đầu triển khai đến phòng mua hàng và chuyển trạng thái cuối cùng thành Completed (Hoàn tất yêu cầu mua sắm). Ở bước này sẽ chuyển dữ liệu qua App 2 Mua hàng.
Tương tự như trên đến bước Pending, nhưng khi bị từ chối sẽ chuyển sang Reject và cuối cùng là Closed. Ở đây, mình có setting một tính năng rework lại đối với những đơn bị từ chối, để người gửi yêu cầu có thể chỉnh sửa lại dòng ghi (nếu bị cân nhắc là sai thông tin,..)
5. Sau khi đã hoàn thiện xong Luồng tự động và phê duyệt, mình sẽ tiếp tục ở bước làm sao để kết nối dữ liệu từ App 1 sang App 2.
App Purchase Request Handling được xây dựng nhằm hỗ trợ quản lý quy trình tạo và phê duyệt yêu cầu mua sắm trong doanh nghiệp. Ứng dụng đóng vai trò là nơi tiếp nhận nhu cầu mua hàng từ các phòng ban trước khi chuyển sang bộ phận Procurement để xử lý mua sắm thực tế. Trong app, người dùng có thể tạo request mới với các thông tin như tiêu đề, phòng ban, loại mua, mô tả chi tiết và chi phí dự kiến( hệ thống sẽ tính tổng tiền dựa trên đơn giá và số lượng của từng đơn hàng). Hệ thống đồng thời tự động quản lý các thông tin hệ thống như số yêu cầu, người tạo và ngày tạo request.
Bên cạnh phần quản lý dữ liệu, app còn được thiết kế workflow xử lý cơ bản giúp phản ánh đúng quy trình nghiệp vụ thực tế. Một request sau khi được tạo sẽ ở trạng thái Draft, sau đó được gửi duyệt sang Pending Approval. Tại đây, người phê duyệt có thể approve hoặc reject yêu cầu. Nếu được phê duyệt, request sẽ chuyển sang trạng thái Approved để tiếp tục xử lý mua sắm ở app Procurement Execution; nếu bị từ chối, request sẽ chuyển sang Rejected và kết thúc quy trình
Tính năng Em thấy hữu ích nhất trong quá trình build là khả năng thiết kế Entity và liên kết dữ liệu linh hoạt trên Cleeksy. Việc có thể phân loại field thành input tay, system field và workflow field giúp mô hình dữ liệu rõ ràng và sát với quy trình nghiệp vụ thực tế hơn. Ngoài ra, Sub-entity hỗ trợ quản lý chi tiết hàng hóa theo từng dòng dữ liệu riêng, kết hợp với Rollup để tự động tính tổng tiền, giúp giảm thao tác thủ công và hạn chế sai sót khi nhập liệu
Ứng dụng đầu tay của mình là Ứng dụng Quản lý Yêu cầu mua hàng (Purchase Request App). Đây là một phân hệ quan trọng trong chuỗi cung ứng của doanh nghiệp, giúp số hóa toàn bộ luồng thông tin từ lúc nhân viên lập đề xuất mua sắm, hệ thống tự động luân chuyển qua các cấp duyệt (Trưởng phòng, Giám đốc), cho đến khi bàn giao sang cho bộ phận thu mua xử lý. Toàn bộ các trường dữ liệu như Mã YCMH, Người yêu cầu, Phòng ban, Tổng tiền, Trạng thái… đều được cấu hình chuẩn hóa trên hệ thống.
Tính năng mình thấy hữu ích nhất trong quá trình build
Điều mình thích nhất và ấn tượng nhất chính là Tính năng Tự động hóa quy trình. Mình có thể cấu hình các trigger tự động vô cùng nhanh chóng. Ví dụ: Khi trạng thái phiếu chuyển thành “Chờ phê duyệt”, hệ thống sẽ tự động gửi thông báo trực tiếp đến tài khoản của Người phê duyệt; hay khi phiếu được duyệt xong thì hệ thống tự động khóa dữ liệu để không ai can thiệp chỉnh sửa được nữa. Việc cấu hình trực quan này giúp mình hiện thực hóa luồng nghiệp vụ cực kỳ nhanh.
Điểm mình thấy còn “chưa quen tay” và cần cải thiện
Phần mình thấy chưa quen tay và còn trăn trở nhất là Thiết kế quy trình hiện tại còn hơi đơn giản. Hiện tại, quy trình phê duyệt trong app của mình rẽ nhánh cơ bản theo hai hướng Đồng ý hoặc Từ chối phê duyệt. Trong thực tế doanh nghiệp, quy trình mua sắm phức tạp hơn rất nhiều với các nhánh rẽ điều kiện. Việc tư duy để thiết kế các kịch bản rẽ nhánh, lồng ghép nhiều điều kiện phức tạp và xử lý luồng khi phiếu bị “Từ chối” quay về bước đầu… là điều mình cần nghiên cứu sâu hơn để quy trình của app trở nên thực tế và “thông minh” hơn. App hiện đã chạy ổn định phần khung dữ liệu và luồng tự động hóa cơ bản. Hành trình tiếp theo của mình là tập trung tối ưu hóa việc liên kết dữ liệu trực tiếp với App Mua hàng . Mục tiêu là ngay khi một Yêu cầu mua hàng được duyệt, toàn bộ thông tin sẽ lập tức tự động đẩy sang phân hệ mua sắm để bộ phận thu mua tiếp quản xử lý nghiệp vụ ngay mà không cần nhập liệu thủ công lại từ đầu.
Chào mọi người, hôm nay mình xin chia sẻ App đầu tiên khi làm quen với Cleeksy DOP
App đầu tiên: Purchase Request Handling (Quản lý yêu cầu mua hàng) → Thông qua quá trình học lý thuyết và thực hành build app đầu tiên, em đã thực hiện được các thao tác cơ bản:
Thiết lập tự động hoá, tạo view, record, form
Tính năng mình thấy hữu ích nhất trong quá trình build
Điểm mình thấy còn “chưa quen tay” và cần cải thiện
Hi mọi người, mình vừa build xong app đầu tiên trên Cleeksy là Purchase Request Handling - app dùng để quản lý quy trình yêu cầu mua hàng nội bộ
Các field chính trong app gồm:
Về giao diện, mình đã tạo List view để quản lý toàn bộ request theo dạng bảng, Kanban view để theo dõi tiến bộ theo từng trạng thái, và một view riêng Pending Approval để lọc các request đang chờ phê duyệt.
Workflow hiện tại của app đang đi theo hướng: Phê duyệt → Processing → In Procurement → Kết thúc
Trong đó, app tập trung vào việc tạo request, phê duyệt và theo dõi trạng thái yêu cầu trước khi dữ liệu được dùng tiếp ở app khác.
Tính năng mình thấy hữu ích nhất là Sub-table / Child table. Mình dùng tính năng này để tạo phần Request Items trong phiếu yêu cầu mua hàng. Thay vì mỗi phiếu chỉ nhập được một vật tư, Sub-table giúp mình nhập nhiều dòng vật tư trong cùng một request, gồm các thông tin như tên vật tư, số lượng, đơn giá và thành tiền. Nhờ vậy, dữ liệu chi tiết của từng yêu cầu được tổ chức rõ ràng hơn và dễ theo dõi hơn
Tính năng mình còn chưa quen tay là phần ánh xạ dữ liệu giữa các app, đặc biệt là cách dùng Data Connection, Lookup và Publish/Consume. Mình vẫn đang tìm hiểu cách xác định field nào nên là dữ liệu gốc, field nào chỉ nên lấy qua tham chiếu, và làm sao để hai app độc lập vẫn có thể đưa dữ liệu qua lại mà không bị nhập trùng hoặc lệch dữ liệu
Hi mọi người,
Em vừa build được app đầu tiên là app Purchase Request (Yêu cầu mua hàng). App này được dùng để hỗ trợ nhân viên tạo và gửi yêu cầu mua hàng, giúp quy trình mua sắm được quản lý tập trung và dễ theo dõi hơn.
Hiện tại app đã có các chức năng cơ bản:
Phân quyền cơ bản theo vai trò
Tạo yêu cầu mua hàng
Danh sách yêu cầu mua hàng
Theo dõi trạng thái xử lý request
Tham chiếu dữ liệu từ app Master Data (danh mục hàng hóa)
Dưới đây là hình ảnh mô tả:
Khởi tạo các trường dữ liệu cần thiết cho hệ thống. Thiết lập tên trường và chọn loại dữ liệu phù hợp (như Mã yêu cầu – đánh số tự động, Chi phí – tổng hợp giá trị, Trạng thái – trắc nghiệm, Người phê duyệt – thành viên)
Màn hình thiết kế bố cục hiển thị của bản ghi, được chia làm 2 phần rõ ràng
Bên trái: Hiển thị các thông tin chi tiết (Thông tin yêu cầu, Thông tin xử lý, Thông tin khởi tạo)
Bên phải: Hiển thị tiến độ (Quy trình bước thực hiện và Công việc)
Tính năng em thấy hữu ích nhất trong quá trình build
Tính năng nào bạn thấy còn chưa quen tay
Vì đây là ứng dụng đầu tiên em tự build nên chắc chắn không tránh khỏi những thiếu sót về mặt logic hay trải nghiệm (UX). Rất mong anh/chị và mọi người xem qua, cho em xin nhận xét và góp ý để em hoàn thiện app tốt hơn ạ. Em cảm ơn mọi người rất nhiều!
Chào các anh chị và các bạn, đây là lần đầu tiên em được tiếp cận cũng như sử dụng một nền tảng low-code, no-code như Cleeksy. Sau một thời gian tìm hiểu, đọc tài liệu và thực hành thì em đã có thể build được app đầu tiên. App đầu tiên là app Yêu cầu mua hàng, được dùng để hỗ trợ nhân viên tạo và gửi yêu cầu mua hàng, giúp quy trình mua sắm được quản lý tập trung, dễ theo dõi và thuận tiện hơn trong việc phê duyệt và xử lý yêu cầu. Và dưới đây là các hình ảnh mô tả:
Hình: Các trường thông tin
Hình: Biểu mẫu
Hình: Quy trình
Hình: Giao diện Bản ghi
Hình: Giao diện Kanban
Về quy trình: Thiết kế workflow theo các trạng thái đề xuất:
- Nhánh đồng ý: Draft → Pending Approval → Approved → In Procurement → Completed → Closed
- Nhánh từ chối: Pending Approval → Rejected → Closed
Tính năng nào bạn thấy hữu ích nhất trong quá trình build ?
Điều em thích và ấn tượng nhất chính là tính năng Tự động hóa quy trình và Khóa trường thông tin. Em có thể cấu hình các trigger tự động khá nhanh và trực quan. Ví dụ như trong workflow của app, khi trạng thái “Pending Approval” được cập nhật thành “Từ chối”, hệ thống sẽ tự động kiểm tra điều kiện và cập nhật trạng thái phiếu sang “Rejected”, đồng thời khóa trường Status để tránh việc chỉnh sửa sai lệch sau khi kết quả đã được xác nhận. Nhờ đó, quy trình xử lý trở nên chặt chẽ và rõ ràng hơn, giúp dữ liệu được kiểm soát tốt và hạn chế các thao tác chỉnh sửa không cần thiết sau phê duyệt.
Tính năng nào bạn thấy còn chưa quen tay?
Phần em thấy còn chưa quen tay nhất là thiết kế Workflow cho app. Hiện tại, workflow em xây dựng vẫn còn khá đơn giản và chưa phản ánh đầy đủ các tình huống thực tế trong doanh nghiệp. Quy trình hiện chủ yếu mới dừng ở các bước cơ bản như tạo yêu cầu, phê duyệt và từ chối, trong khi thực tế sẽ có nhiều trường hợp phát sinh, điều kiện rẽ nhánh và cách xử lý khác nhau giữa các bộ phận. Vì vậy, em thấy mình cần cải thiện thêm tư duy phân tích nghiệp vụ và logic quy trình để có thể thiết kế workflow thực tế, chặt chẽ và tối ưu hơn. Ngoài ra, em cũng còn chưa thật sự quen với việc thực hành các tính năng Tham chiếu dữ liệu, Ánh xạ.
Chào mọi người, em là Nguyễn Mỹ Hạnh - TTS Solution Consultant. Hiện em đang trải qua thời gian thực tập và bắt đầu tiếp cận sâu hơn về Cleeksy App. Sau đây, em xin phép chia sẻ góc nhìn của mình về kết quả tuần đầu tiên.
Sau thời gian làm quen với Cleeksy và tiến hành bắt tay vào thực hiện bước đi xây app đầu tiên của chính mình trên Cleeksy sandbox, em đã hoàn thành cơ bản App 1 - Purchase Request Handling về mô phỏng quy trình xử lý yêu cầu mua sắm nội bộ trong doanh nghiệp.
Tổng quan app Purchase Request Handling và những gì đã thực hiện
App Purchase Request Handling được xây dựng với mục đích giúp nhân viên tạo yêu cầu mua hàng, sau đó chuyển qua bước phê duyệt và tiếp tục trong quá trình xử lý. Thay vì chỉ lưu thông tin request, app còn giúp thể hiện rõ ai đang phụ trách ở từng giai đoạn và một request đang đi đến bước nào trong quy trình.
Hình ảnh 1. Bản ghi
Về workflow, em đã thiết kế luồng chính theo các trạng thái theo yêu cầu để tập làm quen: Draft → Pending Approval → Approved → In Procurement → Completed → Closed
Ngoài ra, app cũng có nhánh xử lý khi yêu cầu không được duyệt: Pending Approval → Rejected → Closed
Hình ảnh 2. Quy trình nghiệp vụ
Khi build flow này, em thấy app phản ánh rõ một quy trình vận hành so với ngoài thực tế: người tạo request, người phê duyệt và bộ phận Procurement không chỉ xuất hiện dưới dạng field thông tin mà thực sự gắn với từng chặng xử lý của yêu cầu.
Tính năng em thấy hữu ích nhất: Process Builder
Tính năng em thấy hữu ích nhất trong quá trình build App 1 là Process Builder.
Trước khi làm bài này, dựa vào cách hiểu của bản thân, em thường hình dung workflow là một cụm từ khá đơn giản: một yêu cầu được tạo ra, rồi chuyển từ trạng thái này sang trạng thái khác cho đến khi hoàn tất quy trình. Nhưng khi trực tiếp dựng quy trình trên Process Builder trên Cleeksy, em mới thấy mỗi bước chuyển trạng thái đều đi kèm với nhiều yêu cầu logic mà mình cần phải nắm rõ hơn như: Ai là người có quyền approve ở bước này? Khi nào một request được phép đi tiếp? Mỗi request sẽ có đường đi như nào và vì sao có logic đó? … và rất nhiều câu hỏi nữa phải xử lý khi đối diện với cấu hình của app mà bản thân cần phải giải quyết.
Em thấy Process Builder hữu ích vì nó giúp biến một quy trình vốn chỉ được mô tả bằng lời thành một flow trực quan, có các checkpoint rõ ràng giữa từng trạng thái. Theo cảm nhận của em, để dựng được một quy trình làm việc sát với thực tế dù với bất kỳ bài toán nghiệp vụ nào, trước hết cũng cần có cái nhìn tổng quan về cách doanh nghiệp vận hành: quy trình bắt đầu từ đâu, đi qua những bước nào, ai tham gia và mỗi bước cần được kiểm soát ra sao.
Tính năng em đang thấy khó khăn: Automation và Permission
Phần em đang cần hiểu kỹ hơn là Automation và Permission, đặc biệt khi kết hợp với workflow.
Ban đầu, hai công cụ này mang đến cho em cảm giác khá mới lạ khi bắt đầu sử dụng. Đối với Automation, em chưa biết là một workflow sẽ được thêm yếu tố automation vào ở đâu và tạo ra ảnh hưởng gì? Còn về Permission, em khá rối vì các tính năng bao gồm cả phê duyệt ở ngoài được set cho app chung, kể cả ở trong mỗi checkpoint đều có luồng phê duyệt của mỗi chính nó, và đặc biệt là em đã thử tự set cả approver trong Automation, mục đích là để sau khi mỗi status chuyển sang trạng thái chờ duyệt “Pending Approval” đồng thời sẽ chuyển giao cho người cụ thể là Approver.
Hình ảnh 3. Permission (luồng phê duyệt)
Hình ảnh 4. Automation
Đây là phần em thấy khá dễ bị rối, vì chỉ cần một logic chưa khớp thì trải nghiệm người dùng trong app có thể không đúng với quy trình mong muốn. Hiện tại em đã được anh Tiến (Mentor) và mọi người trong nhóm thực tập giải đáp các thắc mắc và em vẫn đang tiếp tục thử và kiểm tra thêm để hiểu rõ hơn cách phối hợp giữa workflow – automation – phân quyền sao cho app vừa chặt chẽ, vừa thuận tiện khi sử dụng.
Điều em đúc kết sau tuần đầu
Điều em thấy thú vị nhất sau khi hoàn thành App 1 là build app không chỉ là tạo form và thêm field, mà quan trọng hơn là phải bắt đầu suy nghĩ theo hướng mô hình hóa một quy trình vận hành thực tế.
Việc build app lần này giúp em hiểu rõ hơn vì sao trước khi đi vào giải pháp, cần nắm được flow nghiệp vụ, actor và các tình huống xử lý chính. Đây cũng là phần em thấy bản thân học được nhiều nhất trong tuần đầu tiên.
Chào các bạn.
Từ comment của mọi người, mình thấy rằng các bạn đang cảm thấy bối rối với tính năng Data Connection Two-way (Tham chiếu 2 chiều). Đây là chuyện cực kỳ bình thường đối với những người mới tiếp cận hệ thống kiến trúc dữ liệu.
Để dễ hình dung nhất, các bạn có thể ghi nhớ theo cách này:
1 chiều là “Mối quan hệ Theo dõi”, còn 2 chiều là “Mối quan hệ Hợp tác”.
Tham chiếu 1 chiều: App B kết nối đến App A. App B nhìn thấy dữ liệu của App A để làm việc, nhưng App B không có quyền can thiệp hay làm thay đổi dữ liệu gốc của App A. Dữ liệu chỉ chảy theo một hướng: A → B.
Tham chiếu 2 chiều: App A và App B tương tác trực tiếp trên cùng một “cặp record”. Phía A sửa thì phía B thay đổi, phía B sửa thì phía A cập nhật theo. Dữ liệu tương tác qua lại: A ↔ B. Không có bản sao nào cả, cả hai đang dùng chung một nguồn.
3 Điểm cần chú ý khi thiết kế Tham chiếu 2 chiều
Vì Tham chiếu 2 chiều tạo ra sự ràng buộc dữ liệu rất chặt chẽ, nên nếu thiết kế không khéo, hệ thống của bạn sẽ bị loạn. Dưới đây là 3 điểm các bạn cần chú ý:
Hai trường hợp thực tế áp dụng liên kết 2 chiều
Tại sao dùng tham chiếu 2 chiều?
Phía Lệnh Sản Xuất (Sản xuất nắm quyền): Cập nhật các field Số lượng sản xuất, Xưởng sản xuất, Sản phẩm, Ca làm việc, Tỷ lệ đạt (= Số lượng đạt / Số lượng sản xuất), Tỷ lệ hỏng (= Số lượng hỏng / Số lượng sản xuất).
Phía Lệnh QC (QC nắm quyền): QC mở bản ghi Lệnh QC (đã được link 2 chiều với Lệnh SX), tiến hành nhập các field Số lượng đạt, Số lượng hỏng, và chọn Kết luận QC (SingleOption Đạt / Làm lại).
Cách thức tương tác:
Lệnh Sản xuất tự động cập nhật Tỷ lệ đạt và Tỷ lệ lỗi (Từ phía QC khi nhập Số lượng đạt và Số lượng lỗi).
Nếu QC chọn Kết luận = Làm lại, Lệnh SX lập tức bị đổi trạng thái từ “Chờ nhập kho” về “Đang sản xuất”. Cả 2 phòng ban thao tác trên 2 App khác nhau nhưng thông tin được dệt chặt vào nhau.
Tại sao dùng tham chiếu 2 chiều?
Phía Đề nghị thanh toán (Người đề nghị / Trưởng bộ phận nắm quyền): Cập nhật các field Nội dung thanh toán, Số tiền đề nghị, Thông tin người thụ hưởng, Tổng tiền đã thanh toán (Rollup Số tiền thực chi/thu từ các phiếu chi), Còn lại (= Số tiền đề nghị - Tổng tiền đã thanh toán), Trạng thái thanh toán.
Phía Phiếu thu / Phiếu chi (Kế toán thanh toán / Thủ quỹ nắm quyền): Kế toán tạo bản ghi Phiếu chi/thu (đã được link 2 chiều với Đề nghị thanh toán), tiến hành nhập các field Số tiền thực chi/thu, Phương thức thanh toán, Ngày chứng từ.
Cách thức tương tác:
Đề nghị thanh toán tự động cập nhật số lần đã được thanh toán và Tổng tiền đã thanh toán (Từ phía Kế toán khi hoàn thành các Phiếu thu/chi tương ứng).
Khi Phiếu thu/chi được tạo và tham chiếu đến Đề nghị thanh toán, bên phía Đề nghị thanh toán sẽ tự động tham chiếu ngược lại về Phiếu thu/chi đó, giúp người dùng theo dõi được ngay chứng từ thanh toán mà không cần phải tự tìm và chọn tay như khi dùng tham chiếu 1 chiều.
Cập nhật Trạng thái thanh toán:
Lưu ý thiết kế với Case 2:
Với case này cần lưu ý Phiếu chi là sổ cái bất biến (Immutable). Cần thiết kế để tránh rủi ro: Người ở bên App Đề nghị thanh toán có thể lỡ tay “xóa” hoặc “thay đổi” liên kết đến Phiếu chi.
Chiều từ Đề nghị thanh toán → Phiếu chi: Khi Đề nghị thanh toán được phê duyệt và chuyển sang thực hiện thanh toán, áp dụng quy tắc khóa tất cả các trường và chỉ cho phép đọc (Read-only).
Chiều từ Phiếu chi → Đề nghị thanh toán: Kế toán tạo mới phiếu chi được quyền chọn đề nghị thanh toán cần thực hiện thanh toán.
Chào các anh chị và các bạn, em là Trâm, hiện tại em đang xây dựng chiếc app đầu tay của mình là Purchase Request Handling.
Purchase Request Handling là nơi chịu trách nhiệm khởi tạo và xử lý các yêu cầu mua sắm. App giúp nhân viên dễ dàng đề xuất các yêu cầu mua văn phòng phẩm, trang thiết bị và gửi lên cho bộ phận thu mua quản lí.
Đây là Bảng ghi quản lý danh sách yêu cầu sau khi mình đã tối ưu các cột thông tin thiết yếu và bộ lọc trạng thái.
Đây là Kanban, phân loại Purchase Request theo từng chặng xử lý trực quan, giúp người dùng dễ theo dõi tiến độ hằng ngày.
Luồng quy trình được app được em thiết kế chạy tự động như sau:
Nhân viên tạo yêu cầu (Trạng thái mặc định là Draft)
Chọn người phê duyệt (Chuyển sang bước Chọn người phê duyệt)
Cấp trên tiến hành Phê duyệt (Bước Phê duyệt). Tại đây, nếu bấm Từ chối (Reject), request lập tức chuyển sang Đóng yêu cầu và đi đến chặng Kết thúc. Nếu sếp bấm Đồng ý (Approve), yêu cầu sẽ tự động đổi sang trạng thái Đang mua sắm để sẵn sàng chuyển giao dữ liệu.
Tại bước Đang mua sắm, nếu yêu cầu mua có sự thay đổi về yêu cầu như số lương, hàng hóa thì sẽ có bước Duyệt lại để xác nhận
Sau khi Đang mua sắm, thì sẽ Hoàn thành đơn hàng và Đóng yêu cầu và Kết thúc.
Đây là các trường thông tin của hệ thống:
Tính năng em thấy hữu ích nhất: Tự động hóa và Quy trìnhKhi em được học trên trường lớp, em được dạy cách vẽ workflow đơn giản nhưng khi bắt tay build app rồi thì em nhận ra không như vậy, không đơn giản chỉ là tạo yêu cầu từ bước này đến bước khác. Quy trình ở Cleeksy không chỉ gồm các bước mà còn có các trạng thái khác nhau. Và khi build quy trình, em nhận ra nếu không có tự động hóa, người dùng sẽ phải chỉnh tay rất nhiều thứ và quy trình dễ bị mất logic (ví dụ: nhân viên vô tình sửa lại số tiền sau khi sếp đã duyệt). Nhờ có Tự động hóa, mọi thứ chạy cực kỳ chỉnh chu, dữ liệu được kiểm soát đúng thời điểm giúp quy trình vừa chặt chẽ, vừa an toàn mà không cần ai phải canh chừng.
Tính năng em thấy còn chưa quen tay: Tham chiếu dữ liệu
Khi build app 1, để hệ thống được rõ ràng hơn, em đã xây dựng các app liên quan như Product hay Supplier và sử dụng tham chiếu 1 chiều
Em thấy mình vẫn còn chưa quen tay trong việc sử dụng các tham chiếu này vì nó đòi hỏi về mặt tư duy logic cao hơn, cách kết nối dữ liệu với nhau. Em nghĩ rằng mình cần học hỏi thêm nữa về cách sử dụng các tham chiếu này, để hoàn thiện app mình hơn nữa.
