Luật pháp áp dụng khi chưa thanh toán tiền thưởng cho việc phát triển hệ thống
Đối với những nhà cung cấp dịch vụ phát triển hệ thống, có lẽ rủi ro lớn nhất là “Người dùng không thanh toán phí dù đã nhận hàng”. Chi phí cho việc phát triển hệ thống thường chủ yếu là nhân công, bao gồm các lập trình viên và những người có kỹ năng khác. Do đó, việc phải chi trả nhiều cho nhân công là điều thường xuyên xảy ra. Việc không thu hồi được doanh thu có thể trở thành vấn đề sống còn. Trong bài viết này, chúng tôi sẽ giải thích từ góc độ pháp lý về những điều mà nhà cung cấp nên xem xét trong trường hợp người dùng không đồng ý thanh toán phí.
Đầu tiên, cần xác nhận xem có thể yêu cầu thanh toán hay không
- Nhà cung cấp đã giao hàng cho người dùng, nhưng người dùng không chấp nhận việc giao hàng, do đó việc yêu cầu thanh toán bị trì hoãn
- Mặc dù đã hoàn thành việc kiểm tra, nhưng có sự khác biệt nào đó giữa nhận thức của người dùng và việc không đồng ý thanh toán
Đây là tình huống có thể xảy ra trong thực tế.
Ngoài ra, việc người dùng kiểm tra thông số kỹ thuật của hệ thống đã hoàn thành và chấp nhận việc giao hàng được gọi là “kiểm tra” trong thuật ngữ phát triển hệ thống. Ý nghĩa của việc kiểm tra này và những vấn đề cần xem xét khi tiến trình không tốt được giải thích chi tiết trong bài viết dưới đây.
Bài viết liên quan: Ứng dụng của điều khoản kiểm tra và kiểm tra giả định trong phát triển hệ thống[ja]
Mặc dù bài viết trên đã giải thích tổng quan về việc kiểm tra, từ góc độ pháp lý, cần xem xét liệu việc kiểm tra của người dùng đã hoàn thành hay chưa, bao gồm cả quy định về “điều khoản kiểm tra giả định”.
Với điều này trong tâm trí, điểm cần xem xét đầu tiên khi người dùng không thanh toán là như sau.
- Đầu tiên, công việc đã hoàn thành hay vẫn chưa hoàn thành
- Liệu có thể áp dụng trách nhiệm bảo đảm khiếm khuyết (Điều 635 của Bộ luật dân sự Nhật Bản) hay không
Lý do cần xác nhận hai điểm trên đầu tiên là vì nếu công việc đã hoàn thành và không có trách nhiệm bảo đảm khiếm khuyết (Điều 635 của Bộ luật dân sự Nhật Bản), thì ngay cả khi khởi kiện, không thể mong đợi việc thanh toán.
Vậy, cụ thể, người phụ trách phía nhà cung cấp cần kiểm tra những gì để xem xét hai điểm trên? Dưới đây, chúng ta sẽ xem xét những tài liệu nào cần được xác nhận.
Tài liệu cần kiểm tra để xác định việc yêu cầu thanh toán có thể hay không
| Hóa đơn Nếu không có hóa đơn, điều này sẽ làm tăng giả định rằng việc giao hàng chưa hoàn tất và công việc chưa được hoàn thành. |
| Tài liệu thông báo kết quả kiểm tra Đây là tài liệu quan trọng nhất khi quyết định xem công việc đã hoàn thành hay chưa. Ngoài ra, nếu có trường hợp kiểm tra bị trì hoãn do nguyên nhân của người dùng, bạn cũng nên kiểm tra xem “điều khoản kiểm tra giả định” đã được ghi như thế nào trên hợp đồng. |
| Bảng quản lý vấn đề Đây là tài liệu để biết vấn đề gì đã được phát hiện và cách xử lý như thế nào cho đến nay. Ngoài ra, đây cũng là tài liệu để nắm bắt tình hình về sự cố và lỗi phát sinh sau khi giao hàng, cũng như tình hình sửa chữa. |
| Tài liệu định nghĩa yêu cầu, tài liệu thiết kế và tài liệu quản lý thay đổi, biên bản họp, v.v. Đây là tài liệu để làm rõ việc người dùng và nhà cung cấp ban đầu đã hiểu như thế nào, từ đó làm rõ vấn đề gì nên được gọi là sự cố và lỗi. |
Ngoài ra, chúng tôi đã giải thích chi tiết về cách quản lý thay đổi đặc điểm của hệ thống cần phát triển và cách tạo tài liệu quản lý thay đổi trong một bài viết khác.
Bài viết liên quan: Quản lý thay đổi trong phát triển hệ thống từ góc độ pháp lý là gì[ja]
| Thông báo hủy hoặc tài liệu ghi ý định của người dùng Đây là phương tiện để biết người dùng có ý định gì khi không tiến hành kiểm tra (hoặc không đồng ý thanh toán). |
Tiếp theo, xác nhận số tiền có thể yêu cầu dưới dạng phí
Nguyên tắc là số tiền có thể yêu cầu sẽ được ghi trong hợp đồng. Tuy nhiên, trong trường hợp thông số kỹ thuật được thay đổi sau cùng hoặc không còn hợp đồng chính thức (hoặc tài liệu tương tự), chúng ta cũng cần xem xét. Chúng tôi đã giải thích chi tiết về cách tính lại báo giá dựa trên lý do sau cùng như thay đổi thông số kỹ thuật, thêm chức năng, v.v., trong bài viết dưới đây.
Bài viết liên quan: Có thể tăng số tiền dự toán cho phát triển hệ thống sau cùng không?[ja]
Phương pháp tính lại báo giá được mô tả trong bài viết này, nhưng đặc biệt từ góc độ xem xét việc có thể tăng số tiền yêu cầu hay không, chúng ta cần xem xét các điểm sau:
- Sự có mặt và nội dung của báo giá cho phần phát triển bổ sung, sửa chữa chức năng
- Phản ứng của người dùng đối với báo giá
- Sự có mặt của thỏa thuận về tình huống và số tiền gây ra phát triển bổ sung, sửa chữa chức năng được ghi trong bảng quản lý vấn đề
Điểm chính cần xem xét là liệu có sự đồng lòng giữa người dùng và người yêu cầu về việc “đặt hàng công việc với số tiền đó” (nói cách khác, liệu hợp đồng đã được ký kết hay không).
Cuối cùng, xem xét các vấn đề đang treo trong trường hợp thực sự tiến hành kiện tụng
Chú ý đến khả năng bị kiện ngược
Trong phát triển hệ thống, khi một trong hai bên người dùng hoặc nhà cung cấp khởi kiện đối tác, không hiếm khi họ lại bị đối tác khởi kiện ngược. Nói cách khác, đây là tình huống không thanh toán tiền công, và có lẽ người dùng cũng có lý do gì đó để phản đối.
Đầu tiên, phát triển hệ thống đòi hỏi người dùng phải chịu nhiều nghĩa vụ hợp tác, nhưng trước hết, chúng ta không nên quên rằng nhà cung cấp chịu trách nhiệm lớn và có quyền tự do rộng lớn như một chuyên gia phát triển hệ thống. Chúng tôi đã giải thích chi tiết về nghĩa vụ quản lý dự án mà nhà cung cấp phải chịu trong phát triển hệ thống trong bài viết dưới đây.
Bài viết liên quan: Nghĩa vụ quản lý dự án trong phát triển hệ thống là gì[ja]
Nói cách khác, chúng ta cần xem xét kỹ lưỡng trước liệu có thể đổ lỗi cho người dùng vì không thanh toán tiền công một cách đơn phương hay không. Khi xem xét các ví dụ kiện tụng trong quá khứ, có nhiều trường hợp mà ban đầu nhà cung cấp yêu cầu thanh toán tiền công và khởi kiện, nhưng sau đó người dùng ngược lại, yêu cầu nghĩa vụ phục hồi trạng thái ban đầu và bồi thường thiệt hại.
Cũng cần xem xét liệu có lợi ích thực sự trong kinh doanh hay không
Ngay cả khi lập trường của nhà cung cấp được chấp nhận và việc yêu cầu thanh toán tiền công thực sự có thể được công nhận trong kiện tụng, nếu tình hình leo thang đến mức kiện tụng, việc tiếp tục giao dịch sau đó dự kiến sẽ gặp khó khăn. Thêm vào đó, ngay cả khi lập trường của bạn được công nhận trong kiện tụng, bạn cũng nên chuẩn bị cho việc mất khá nhiều thời gian để nhận được tiền công. Nếu bạn xem xét việc kiện tụng sẽ tốn kém và mất thời gian, có lẽ nên cố gắng tìm ra một điểm thỏa hiệp sẽ là lựa chọn hợp lý và tốt hơn.
Tóm tắt
Nếu người dùng không tuân theo việc thanh toán phần thưởng, khi cố gắng xem xét vấn đề này theo pháp luật, bạn sẽ cần phải xác minh nhiều loại tài liệu khác nhau. Hơn nữa, không chỉ cần quản lý tài liệu một cách kỹ lưỡng, bạn cũng cần xem xét các vấn đề như rủi ro và nhược điểm tổ chức mà bạn có thể phải đối mặt nếu bạn quyết định kiện.
Việc quản lý tài liệu hàng ngày thường thuộc về công việc ở cấp độ hiện trường. Tuy nhiên, nếu bạn quyết định kiện dựa trên các tài liệu và tài liệu đã lưu trữ, điều này có thể trở thành một quyết định quản lý quan trọng. Trong những tình huống bất thường như vậy, sức mạnh tổ chức và sự đoàn kết giữa cấp quản lý và cấp hiện trường sẽ được thử thách. Bạn nên nắm bắt toàn bộ quá trình này.
Category: IT
Tag: ITSystem Development
