ERPNext cho bệnh viện tư: sổ kho vật tư, sổ cái và điều kiện thử nghiệm
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
ERPNext cho bệnh viện tư: nên thử ở khâu hậu cần nào và nên dừng ở đâu
ERPNext là một hệ thống ERP, tức phần mềm hoạch định nguồn lực doanh nghiệp, gom kế toán, kho, mua bán, sản xuất, tài sản và dự án vào cùng một cơ sở dữ liệu. README của dự án tự mô tả đây là hệ thống ERP mã nguồn mở và liệt kê năm nhóm chức năng chính: kế toán, quản lý đơn hàng, sản xuất, quản lý tài sản và dự án. Phần nền kỹ thuật là Frappe Framework, một framework web viết bằng Python và JavaScript. [1]
Bài này xem xét ERPNext dưới góc nhìn của một bệnh viện tư. Kết luận sơ bộ là hệ thống đáng cân nhắc cho lớp hậu cần và sổ sách: kho vật tư tiêu hao, mua hàng, công nợ phải trả, tài sản thiết bị. Danh sách chức năng trong README không nhắc tới hồ sơ bệnh án, y lệnh hay viện phí, nên bài không coi ERPNext là hệ thống thông tin bệnh viện. [1]
Chứng từ về muộn, giá vốn đổi theo: bài toán sổ kho trong bệnh viện
Trong một bệnh viện tư quy mô vừa, vật tư tiêu hao, hóa chất xét nghiệm và dụng cụ phẫu thuật đi qua nhiều tay: kho trung tâm nhận hàng, các khoa lĩnh về, nhà cung cấp giao từng đợt, hóa đơn có khi đến sau hàng nhiều ngày. Đây là mô tả giả định của bài, dùng để định khung vấn đề chứ không phải số liệu khảo sát. Khi sổ kho nằm trong bảng tính và sổ kế toán nằm ở phần mềm khác, mỗi cuối tháng đội kế toán phải dựng lại câu chuyện của từng mặt hàng.
Điểm khó nhất là giá trị tồn kho phụ thuộc thứ tự thời gian. Một phiếu nhập được ghi bổ sung cho ngày hôm trước làm thay đổi số tồn và giá vốn của mọi giao dịch phía sau nó. Tài liệu triển khai của ERPNext gọi đây là giao dịch lùi ngày (backdated transaction) và giải thích rằng sổ kho có trạng thái, giữ hàng đợi và số lượng tại từng thời điểm, nên một giao dịch lùi ngày buộc các giá trị tương lai phải được tính lại. [6]
ERPNext tiếp cận bằng cách biến mỗi biến động kho thành một dòng trong Stock Ledger, gắn với chứng từ gốc, rồi đẩy phần chênh lệch giá trị vào sổ kế toán. Nhờ vậy câu hỏi "vì sao giá trị tồn của mặt hàng này khác tháng trước" có thể truy về chứng từ cụ thể. [5]
Hai cuốn sổ chạy song song: Stock Ledger Entry và General Ledger
Về tầng nền, README cho biết ERPNext chạy trên Frappe Framework, thư viện cung cấp lớp trừu tượng cơ sở dữ liệu, xác thực người dùng và REST API, cùng Frappe UI là thư viện giao diện dựa trên Vue. Ứng dụng ERPNext được cài vào một "site" bằng công cụ bench với các lệnh tạo site, tải ứng dụng và cài ứng dụng. [1] Như vậy ERPNext là một ứng dụng chạy trên framework, không phải một khối đơn lẻ.
Ở tầng nghiệp vụ, tài liệu về sổ kho mô tả Stock Ledger Entry là một dòng ghi nhận thay đổi tồn kho của một mặt hàng tại một kho. Mỗi dòng có số lượng thay đổi, số lượng sau giao dịch, giá nhập, thời điểm hạch toán, loại và mã chứng từ gốc, giá trị tồn, chênh lệch giá trị, và hàng đợi dùng để tính giá khi áp dụng FIFO hoặc LIFO. [5] Việc dòng sổ nào cũng trỏ về chứng từ tạo ra nó là nền cho khả năng truy vết.
Ở phía kế toán, module Accounts quản lý hệ thống kế toán kép truyền thống với cây tài khoản, bút toán nhật ký, hóa đơn bán và hóa đơn mua theo từng mặt hàng; mọi bút toán được lưu trong General Ledger. Riêng các giao dịch trên tài khoản phải thu và phải trả còn được ghi vào Payment Ledger để việc đối chiếu thanh toán chỉ cần cập nhật sổ này. [7]
Từ phiếu nhập kho đến bút toán: đường đi của một giao dịch và hàng đợi tính lại
Theo tài liệu sổ kho, việc tạo dòng Stock Ledger thường bắt đầu từ một giao dịch kho, như phiếu nhập hoặc hóa đơn mua có cập nhật kho, gọi phương thức update_stock_ledger. Phương thức này tạo các đối tượng dòng sổ; hàm make_sl_entries trong stock_ledger.py ghi chúng vào cơ sở dữ liệu; lớp update_entries_after xử lý hàng đợi và giá trị của đúng dòng vừa chèn. [5] Đây là phần đồng bộ của luồng.
Phần còn lại không đồng bộ. Thay đổi về số lượng được lan sang các dòng tương lai ngay lập tức, còn giá trị và hàng đợi của các dòng tương lai được xử lý nền bằng cơ chế Repost Item Valuation. [5] Tài liệu reposting nói rõ khi phát hiện giao dịch lùi ngày, hệ thống không xử lý đầy đủ ngay lúc ghi nhận mà xếp yêu cầu vào hàng đợi; một tác vụ định kỳ mỗi giờ xử lý hàng đợi trong tối đa 25 phút. [6]
Mỗi yêu cầu có trạng thái mặc định là Queued, chuyển sang In Progress khi được xử lý và Completed khi xong, ngoài ra còn Failed và Skipped. Yêu cầu nháp hoặc đã hủy bị bỏ qua. [6] Hệ quả vận hành là sau khi nhập một phiếu lùi ngày, giá vốn hiển thị có thể chưa phản ánh ngay; đội kế toán nên xem trạng thái hàng đợi trước khi chốt kỳ. Đây là suy luận từ mô tả cơ chế, chưa được kiểm chứng bằng thao tác thực tế.
Những gì tài liệu đã xác nhận và những gì chưa tìm thấy bằng chứng
Những điều có thể khẳng định từ nguồn đã đọc như sau. README liệt kê kế toán, quản lý đơn hàng gồm tồn kho, đơn bán, khách hàng, nhà cung cấp, giao nhận; sản xuất; quản lý tài sản từ mua đến thanh lý; và dự án với công việc, bảng chấm công, sự cố. [1] README cũng cho biết có bản demo trực tuyến, kênh học tập Frappe School, diễn đàn và nhóm Telegram. [1]
Về kho, tài liệu kỹ thuật nêu các trường dữ liệu của sổ kho, cách tính giá bằng hàng đợi FIFO hoặc LIFO, việc dòng bị hủy được đánh dấu để không tham gia logic nghiệp vụ, và quy tắc xử lý số sê-ri cùng lô hàng. [5] Về chất lượng dữ liệu, tài liệu reposting nêu bốn báo cáo dùng để phát hiện dữ liệu kho hỏng: số lượng sau giao dịch sai, giá trị tồn sai, định giá số sê-ri sai và báo cáo kiểm tra bất biến của sổ kho. [6]
Về kế toán, tài liệu mô tả cây tài khoản, bút toán nhật ký, hóa đơn và Payment Ledger. [7] Những mục này đủ để lập kế hoạch thử nghiệm phần kho và công nợ.
Những điều chưa có bằng chứng trong các tệp đã đọc cũng cần ghi rõ: chức năng lâm sàng cho bệnh viện, bộ tài khoản và biểu mẫu theo chuẩn Việt Nam, hóa đơn điện tử, kết nối bảo hiểm y tế, quy trình sao lưu và nâng cấp chi tiết. Bài không khẳng định hệ thống có hay không có những khả năng đó; đội thử nghiệm phải kiểm chứng trong tài liệu chính thức và môi trường của mình.
Ai nên thử ERPNext và ai nên đi hướng khác
ERPNext phù hợp trước hết với đơn vị muốn kiểm soát dữ liệu quản trị của mình và có nguồn lực kỹ thuật để vận hành. README đưa ra hai lối đi: dùng dịch vụ lưu trữ Frappe Cloud, hoặc tự triển khai bằng Docker hay bench. [1] Lối thứ hai đòi hỏi người quản trị hệ thống thực thụ, không chỉ người dùng nghiệp vụ.
Trong lĩnh vực y tế, nhóm phù hợp là bộ phận quản trị của bệnh viện hoặc chuỗi phòng khám tư cần một sổ kho vật tư có truy vết, hệ thống mua hàng và công nợ rõ ràng, và sổ tài sản thiết bị. Các bộ phận này làm việc với chứng từ và số liệu, đúng phạm vi mà README mô tả. [1] Đơn vị có đội IT nhỏ hoặc đối tác triển khai có thể tận dụng việc mã nguồn mở để tùy biến.
Tình huống đề xuất: bệnh viện tư 120 giường thử sổ kho vật tư tiêu hao
Đây là tình huống giả định, không phải trường hợp đã xảy ra. Hãy hình dung một bệnh viện đa khoa tư nhân khoảng 120 giường tại một thành phố loại hai, có một kho trung tâm và ba kho khoa: xét nghiệm, phòng mổ, nội trú. Hiện sổ kho nằm trong bảng tính, hóa đơn nhà cung cấp được kế toán nhập vào phần mềm kế toán riêng, và cuối tháng hai bên mất nhiều ngày để khớp số liệu.
Đề xuất là chỉ thử ERPNext cho vật tư tiêu hao, hóa chất xét nghiệm và công cụ dụng cụ. Phạm vi gồm danh mục mặt hàng, nhà cung cấp, đơn mua, phiếu nhập, phiếu xuất cho khoa, kiểm kê và công nợ phải trả. Các nhóm chức năng này tương ứng với phần quản lý đơn hàng và kế toán trong README. [1] Dữ liệu bệnh nhân, thuốc kê đơn theo từng ca và viện phí hoàn toàn nằm ngoài phạm vi; điều này giữ rủi ro dữ liệu cá nhân ở mức thấp trong giai đoạn đầu.
Vai trò tham gia gồm thủ kho trung tâm, kế toán kho, kế toán công nợ, trưởng khoa lĩnh vật tư và một cán bộ CNTT. Phần quản lý tài sản mà README nhắc tới có thể là giai đoạn hai cho máy móc thiết bị, nhưng bài không biết cách tính khấu hao có khớp quy định trong nước hay không nên đưa vào danh sách kiểm chứng. [1]
Dựng môi trường: Docker để xem thử, hạ tầng riêng để chạy thật
README tách rõ hai mức. Mức đầu là cấu hình Docker Compose trong kho frappe_docker, được ghi chú là chỉ dùng để đánh giá nhanh, mong đợi sẽ bị vứt bỏ và không cài được ứng dụng tùy biến; tài khoản mặc định được nêu ngay trong README. [1] Cấu hình này phù hợp để nhân viên kinh doanh hoặc kế toán làm quen giao diện, tuyệt đối không dùng với dữ liệu thật.
Mức hai là triển khai production theo tài liệu đầy đủ. README dẫn tới tài liệu Docker chính thức, hướng dẫn cài bench và hướng dẫn dịch vụ Frappe Cloud. Với cài thủ công, README nhắc script cài đặt sẽ tự dựng các thành phần phụ thuộc như MariaDB và tạo mật khẩu cho tài khoản quản trị. [1] Vì vậy bệnh viện cần chọn: tự vận hành máy chủ, thuê đối tác, hay dùng dịch vụ lưu trữ do nhà phát triển cung cấp.
Phân quyền, dữ liệu nhạy cảm và kênh báo cáo lỗ hổng
Về chính sách, tệp SECURITY.md của ERPNext rất ngắn: nhóm dự án khẳng định coi trọng vấn đề an ninh và hướng dẫn người báo cáo theo quy trình công bố có trách nhiệm trên trang bảo mật của Frappe, đồng thời hứa phản hồi nhanh. [3] README cũng dẫn một liên kết riêng để báo lỗ hổng. [1] Hai tệp này không nêu thời hạn vá lỗi hay phiên bản nào còn được hỗ trợ, nên bệnh viện không thể dựa vào chúng để cam kết mức dịch vụ.
Dù phạm vi thử nghiệm không chứa dữ liệu bệnh nhân, bệnh viện vẫn có dữ liệu nhạy cảm như hợp đồng nhà cung cấp, giá mua và công nợ. Khuyến nghị gồm phân quyền tối thiểu theo vai trò, tách môi trường thử với môi trường thật, sao lưu có mã hóa và ghi lại ai giữ quyền quản trị. Nếu mở rộng sang dữ liệu liên quan người bệnh, cần rà soát lại theo quy định bảo vệ dữ liệu cá nhân và quy định ngành y tế của Việt Nam với tư vấn pháp lý.
GPLv3, nhãn hiệu ERPNext và ranh giới của phạm vi cấp phép
Tệp license.txt tại commit đã chọn là toàn văn GNU General Public License phiên bản 3. [2] Trường giấy phép mà GitHub hiển thị cũng ghi GPL-3.0, nhưng bài dựa vào văn bản đã đọc chứ không chỉ dựa vào trường đó. Về thực tế, GPLv3 là giấy phép copyleft: khi phân phối bản đã sửa đổi, người phân phối phải cung cấp mã nguồn theo cùng điều kiện. Việc bệnh viện tự chạy nội bộ không đồng nghĩa với việc phân phối cho bên khác, nhưng ranh giới này nên được luật sư xác nhận, nhất là nếu đối tác triển khai đóng gói lại.
Về nhãn hiệu, chính sách của dự án nói tên ERPNext và logo là nhãn hiệu của Frappe Technologies. Việc dùng tên hoặc logo trong tên dự án, sản phẩm, dịch vụ, tên miền hay tên công ty cần được Frappe cho phép. Một đơn vị tư vấn được mô tả dịch vụ ERPNext của mình nhưng không được đặt tên doanh nghiệp theo kiểu gây hiểu nhầm là chính thức, và chính sách không cho dùng nhãn hiệu trong quảng cáo trả tiền. [4]
Giấy phép này chỉ bao phủ mã nguồn trong kho tại commit đang xét. Nó không bao gồm dịch vụ Frappe Cloud, dữ liệu của bệnh viện, các ứng dụng bổ sung của bên thứ ba, hay các thư viện phụ thuộc mà mỗi cái có điều khoản riêng. README cho thấy Frappe Framework và Frappe UI là các kho riêng; bài chưa đọc giấy phép của chúng. [1] Vì vậy cần rà soát giấy phép đầy đủ trước khi triển khai thực tế.
Chi phí thử nghiệm: loại nguồn lực chứ không phải con số giá
Con người là khoản lớn nhất: một người dẫn dự án phía nghiệp vụ có thẩm quyền chốt quy tắc kho và kế toán; một thủ kho và một kế toán kho dành một phần thời gian để nhập liệu song song; một kỹ sư có kinh nghiệm Python, MariaDB và Docker hoặc một đối tác triển khai; và thời gian của người dùng ở các khoa để được hướng dẫn. Giờ làm song song hai hệ thống là chi phí dễ bị bỏ quên nhất.
Hạ tầng gồm máy chủ ứng dụng và cơ sở dữ liệu cỡ nhỏ cho môi trường thử, môi trường tách biệt cho kiểm thử nâng cấp, dung lượng lưu trữ cho sao lưu, và kết nối mạng nội bộ ổn định giữa các kho. Vì README nhắc tới MariaDB làm thành phần phụ thuộc và Docker làm lối cài chính, đội kỹ thuật có thể ước lượng theo hai thành phần này. [1] Nếu chọn Frappe Cloud, khoản máy chủ chuyển thành phí dịch vụ; bài không biết mức phí. [1]
So sánh cách tiếp cận: ERP mã nguồn mở, ERP cùng họ, phần mềm kế toán trong nước và hệ thống thông tin bệnh viện
Một phương án là giữ phần mềm kế toán trong nước và bổ sung quản lý kho bằng module riêng của nhà cung cấp đó. Ưu điểm thường là bám sát biểu mẫu quen thuộc; hạn chế là hai sổ có thể lệch nhau nếu không tích hợp chặt. ERPNext đặt kho và kế toán trong cùng cơ sở dữ liệu với liên kết tới chứng từ, nên bài toán đối chiếu có khả năng giảm, song bài chưa đo được điều đó. [5]
Phương án thứ hai là một ERP mã nguồn mở khác như Odoo, vốn cũng là bộ ứng dụng kinh doanh tích hợp. Hai hệ thống đáp ứng cùng loại nhu cầu, nhưng khác nhau về framework, cộng đồng, giấy phép và mô hình sản phẩm; quyết định nên dựa vào bản dùng thử với dữ liệu của chính bệnh viện hơn là bảng so sánh tính năng chung chung. Bài không đưa ra khẳng định hơn kém giữa hai bên.
Những giới hạn và điều kiện không nên dùng ERPNext
Giới hạn đầu tiên là phạm vi. README không liệt kê chức năng lâm sàng, nên không thể dùng ERPNext thay hồ sơ bệnh án hay quản lý khám chữa bệnh dựa trên nguồn đã đọc. [1] Giới hạn thứ hai là bản địa hóa: bộ tài khoản, hóa đơn điện tử và biểu mẫu Việt Nam chưa được xác minh trong các tệp này.
Giới hạn thứ ba nằm ở thiết kế sổ kho. Giá trị của các dòng tương lai được tính lại ở nền theo lịch mỗi giờ, trong tối đa 25 phút mỗi lần chạy, nên số liệu có thể chưa nhất quán ngay sau khi nhập giao dịch lùi ngày. [6] Với bệnh viện có nhiều phiếu nhập bổ sung, điều này đòi hỏi quy trình chốt kỳ có bước chờ hàng đợi.
Giới hạn thứ tư là cách xử lý lô và số sê-ri. Tài liệu ghi lô chưa được tính theo giá riêng mà dùng hàng đợi FIFO chung, và số sê-ri không theo cấu hình định giá của mặt hàng. [5] Nếu bệnh viện cần quản lý hạn dùng và giá theo từng lô thuốc hoặc hóa chất, phải kiểm tra phiên bản hiện hành. Tài liệu này là ghi chú triển khai nội bộ, có thể đã lệch với mã mới.
Kế hoạch 12 tuần: bốn giai đoạn, tiêu chí đo được và điều kiện dừng
Giai đoạn một, tuần 1 đến 2, là chuẩn bị. Đọc tài liệu chính thức về triển khai, dựng môi trường thử bằng Docker, xác định danh mục khoảng vài trăm mặt hàng đại diện, chọn một kho trung tâm và một kho khoa. Tiêu chí hoàn thành: có biên bản chốt phạm vi, danh sách vai trò và danh sách câu hỏi mở về bản địa hóa, lô hàng và hóa đơn điện tử.
Giai đoạn hai, tuần 3 đến 6, là nạp dữ liệu và kiểm tra cơ chế. Nạp số dư đầu kỳ, nhập lại ba tháng chứng từ cũ để so với sổ hiện tại, cố ý tạo một số phiếu nhập lùi ngày để quan sát hàng đợi tính lại. [6] Tiêu chí đề xuất: chênh lệch số lượng tồn giữa ERPNext và kiểm kê thực tế bằng không cho nhóm vật tư được chọn, và mọi chênh lệch giá trị đều giải thích được bằng chứng từ cụ thể.
Giai đoạn ba, tuần 7 đến 10, là chạy song song. Thủ kho và kế toán dùng cả hai hệ thống. Chạy bốn báo cáo kiểm tra dữ liệu kho mỗi tuần và ghi kết quả. [6] Đo thêm thời gian từ lúc nhận hàng đến lúc phiếu nhập và hóa đơn được đối chiếu, cùng số ngày để kế toán khóa sổ so với hiện tại. Các ngưỡng cụ thể do bệnh viện đặt từ đầu, không lấy từ nguồn nào.
Giai đoạn bốn, tuần 11 đến 12, là ra quyết định. Điều kiện dừng: có yêu cầu pháp lý hoặc kế toán không thể đáp ứng, có yêu cầu giá theo lô không thể cấu hình, hàng đợi Failed lặp lại không giải thích được, hoặc chi phí vận hành vượt ngân sách đã duyệt. [5] Điều kiện tiếp tục: đạt tiêu chí số liệu, người dùng ở kho và kế toán chấp nhận quy trình, và rà soát giấy phép, bảo mật hoàn tất.
Kết luận: một cuốn sổ kho có truy vết, với điều kiện phải kiểm chứng phần bản địa
ERPNext là ứng viên đáng thử cho phần hậu cần của bệnh viện tư vì nó đặt kho, mua hàng và kế toán trong một mô hình dữ liệu có truy vết chứng từ, được mô tả khá chi tiết trong tài liệu kỹ thuật của chính dự án. [5][7] Các cơ chế như tính lại giá cho giao dịch lùi ngày và báo cáo kiểm tra bất biến cho thấy dự án đã đối mặt với các vấn đề thực tế của sổ kho. [6]
Nhưng nguồn đã đọc không chứng minh được rằng hệ thống đáp ứng quy định Việt Nam, đáp ứng giá theo lô hay đủ an toàn cho môi trường y tế. Bất kỳ quyết định triển khai nào cũng cần thêm tài liệu chính thức, rà soát pháp lý và thử nghiệm bằng dữ liệu thật đã ẩn danh. Giấy phép GPLv3 và chính sách nhãn hiệu cho phép sử dụng nội bộ rõ ràng, nhưng cần xem xét khi có phân phối lại hoặc đặt tên thương mại. [2][4]
Nguồn và phương pháp: desk research tại một commit cố định
Đây là nghiên cứu trên tài liệu (desk research) tại commit 3b20e6bced13982f6518697f45d76edae82af7ad, có ngày commit 12/10/2026, kiểm tra ngày 12/10/2026. Tác giả không cài đặt, không chạy, không đo hiệu năng hay triển khai ERPNext. Mọi nhận định kỹ thuật dựa trên các tệp đã đọc: README, license.txt, SECURITY.md, chính sách nhãn hiệu, ghi chú triển khai sổ kho, tài liệu reposting và README module kế toán. [1][2][3][4][5][6][7]
Việc chọn dự án đến từ kho lưu trữ GitHub Trending do cộng đồng duy trì. Theo dữ liệu thu thập của loạt bài, ERPNext xuất hiện 5 lần trên danh sách Python từ ngày 29/01/2026 đến 15/06/2026, lần đầu ở vị trí thứ 9; trang bằng chứng được dẫn ở đây. [8] Kho lưu trữ chỉ có danh sách Python, Go, JavaScript và Swift, thiếu các ngày 03/09/2026 và 12/10/2026, nên đây không phải bảng xếp hạng top 100 chính thức.
Bài không phải công bố khoa học đã qua bình duyệt. Các phần kịch bản Việt Nam, chi phí và kế hoạch thử nghiệm là phân tích và đề xuất của tác giả, đã được đánh dấu là giả định. Tài liệu kho mã được coi là dữ liệu tham khảo, không phải chỉ dẫn. Những mục chưa xác minh gồm bản địa hóa Việt Nam, phân quyền chi tiết, quy trình sao lưu và giấy phép của Frappe Framework.
Xem mã nguồn ERPNext trên GitHub