3.1.1 Sự cần thiết phải xây dựng ứng dụng tra soát liên Ngân hàng
Hiện tại ở Việt Nam, thanh toán qua thẻ đã trở thành nhu cầu không thể thiếu được. Với việc thanh tốn qua thẻ, cơng việc thanh tốn lương hàng tháng cho nhân viên sẽ trở nên đơn giản hơn đối với các cơ quan, doanh nghiệp. Họ sẽ khơng cịn phải th nhiều nhân viên để tham gia trả tiền lương hàng tháng, họ cũng không cần phải dự trữ cũng như vận chuyển nhiều tiền mặt để đem trả lương cho nhân viên - điều đó hạn chế được rất nhiều rui ro mất tiền. Các chủ sở hữu thẻ sẽ không cần phải mang một số tiền lớn đi ra ngồi, thay vào đó họ chỉ cần cầm chiếc thẻ đi và có thể sử dụng vào việc rút tiền ở bất cứ đâu, hay sử dụng thẻ trực tiếp vào việc thanh toán. Rõ ràng là việc sử dụng thẻ ngày càng trở nên không thể thiếu đối với hầu hết mọi người.
Hiện tại, các ngân hàng đang tích cực thạm gia vào việc phát hành thẻ. Nhưng một vấn đề đặt ra là nếu các ngân hàng tự đầu tư hệ thống ATM sử dụng cho việc rút tiền thì chi phí sẽ rất lớn, mà trong khi đó khơng tận dụng được tối đa khả năng sử dụng của các máy ATM. Do đó, các ngân hàng đã liên kết lại thông qua những công ty làm cầu nối trung gian như Banknetvn, SMARTLINK để có thể thơng qua đó, sử dụng chung một hệ thống máy ATM. Điều đó tạo sự thuận lợi rất lớn cho các ngân hàng. Tuy nhiên, việc sử dụng thông qua chung một công ty như vậy lại phát sinh ra những vấn đề mới. Đó là xảy ra tình trạng ngân hàng này sẽ thanh tốn cho ngân hàng khác và như vậy có khả năng sẽ dẫn đến việc tranh chấp giữa các ngân hàng. Vì vậy địi hỏi tổ chức phải có một trung gian để thực hiện việc thanh toán cũng như giải quyết tranh chấp khi thanh toán cho các ngân hàng.
Hiện tại, việc tranh chấp giải quyết được thực hiện một cách thủ công, qua nhiều giai đoan, bao gồm:
Công ty chuyển mạch tài chính Banknetvn sẽ phân loại từng giao dịch theo các ngân hàng,kiểm tra sơ bộ, lưu giữ lại một bản copy và chuyển một bản sang cho bên ngân hàng cần phải thực hiện tra soát dạng fax
Ngân hàng thực hiện nghĩa vụ tra soát sẽ tiến hành kiểm tra giao dịch theo yêu cầu, báo lại cho Banknetvn kết quả kiểm tra bằng văn bản fax.
Banknetvn dựa trên kết quả kiểm tra này sẽ tổng hợp và báo lại với ngân hàng phát sinh yêu cầu dưới dạng văn bản fax.
Quá trình như trên được thực hiện sẽ làm chậm tiến trình tra sốt cũng như việc tổng hợp xem xét của các bên. Chính vì nhu cầu trên, việc xây dựng hệ thống tra soát liên ngân hàng trợ giúp cho việc tra soát những giao dịch tranh chấp giữa các ngân hàng. Chương trình này cho phép bên phát sinh ra tranh chấp có thể cập nhật những thơng tin về giao dịch để yêu cầu bên thanh toán hộ tra sốt lại hịng tìm ra xem giao dịch đã thực hiện có đúng là thành cơng hay khơng. Ngồi ra chương trình cịn trợ giúp cho bên trung gian (là bên xây dựng ứng dụng tra sốt) có thể xem kết quả tra sốt để hỗ trợ các bên liên quan trong q trình tra sốt khi có u cầu cần thiết. Chương trình cũng hỗ trợ việc xuất ra báo cáo cho các bên theo thời gian để có thể ước lượng cũng như đánh giá tổng quát về số lượng cũng như chi tiết từng giao dịch đã tra soát và những giao dịch đang trong quá trình tra sốt.
Một vấn đề đặt ra rất được quan tâm đối với luận văn này là việc xây dựng ứng dụng tra sốt trên đám mây có lợi ích gì so với việc xây dựng ứng dụng cài đặt tại máy chủ thơng thường. Liệu những lợi ích khác biệt này mang lại có đủ để thúc đẩy việc đưa ứng dụng này lên đám mây không? Rõ ràng việc xây dựng ứng dụng trên đám mây mang lại những ý nghĩa dưới đây:
Với việc đưa dữ liệu lên đám mây, người quản trị ứng dụng khơng cịn phải lo tới
việc bảo trì hệ thống để làm cho ứng dụng vận hành trơn tru. Công việc này sẽ được phải nhà cung cấp dịch vụ (Microsoft) đảm nhiệm.
Công việc quản trị sao lưu phục hồi CSDL cũng được tự động hóa thực hiện, đảm
bảo dữ liệu không bị mất (do được sao lưu thành 3 bản), và do đó đảm bảo ứng dụng không bị mất dữ liệu
Tổ chức Banknetvn không phải lo tới việc đầu tư nâng cấp phần cứng. Công việc
này sẽ được Microsoft thực hiện, đảm bảo cho việc ứng dụng hoạt động đúng theo yêu cầu
Khả năng mở rộng/ thu hẹp phạm vi dịch vụ nhanh. Khi cần tăng tốc độ ứng
dụng, chỉ cần khai báo cấu hình cần thay đổi trong một tệp cấu hình đã được định nghĩa sẵn. Hệ thống Windows Azure sẽ tự động cập nhật thay đổi cấu hình và sẽ khởi tạo các tham số để đáp ứng với sự thay đổi cấu hình này. Chẳng hạn, khi muốn tăng số thể hiện ứng dụng đang chạy, chỉ cần thay đổi tham số tương ứng với số lượng thể hiện trong tệp cấu hình. Khi lưu trữ trên những máy chủ của nhà cung cấp dịch vụ thơng thường, muốn thay đổi cấu hình khách hàng phải làm đơn từ và ký kết khá phức tạp.
Giảm chi phí đầu tư ban đầu do việc thanh toán tiền sử dụng dịch vụ mềm dẻo.
Việc thanh toán diễn ra dựa trên nhu cầu sử dụng dịch vụ, được thực hiện dưới dạng trả sau. Điều này khác với việc lưu trữ ứng dụng trên máy chủ của nhà cung cấp dịch vụ bình thường, vì khách hàng phải ký kết hợp đồng trả tiền hàng tháng với một khoản cố định.
Tốc độ ứng dụng cũng sẽ được cải tiến so với các ứng dụng được lưu trữ trên
máy chủ của nhà cung cấp dịch vụ thông thường. Do đám mây có sử dụng kĩ thuật điện tốn lưới (trong đó sử dụng cơng nghệ tính tốn song song) lên ứng dụng đảm bảo được xử lý ở tốc độ cao. Đây là một lợi thế không nhỏ do các ứng dụng trên Internet thường bị điểm yếu về tốc độ.
3.1.2 Khảo sát phân tích nghiệp vụ
Đối tượng sử dụng: Đối với Ngân Hàng phát hành thẻ là tra soát viên (TSV) và kiểm soát viên (KSV) của ngân hàng phát hành. Ngân hàng thanh tốn có tra sốt viên (TSV) và kiểm soát viên (KSV) của ngân hàng thanh tốn.
Tại TCPHT có các u cầu phát sinh như dưới đây:
Nhập YCTS lần 1: TSV của các tổ chức phát hành thẻ sẽ cập nhật vào chương trình và nhập các yêu cầu tra sốt. Những thơng tin về yêu cầu tra soát bao gồm: Ngày giao dịch, giờ giao dịch, Mã thiết bị, Số thẻ, Số trace, Tổ chức chấp nhận thẻ (Acquirer), Tổ chức thanh toán thẻ (Issuer), Mã tra soát (theo bảng mã, tham khảo phụ lục bảng mã tra soát), Số tiền tra sốt (nếu có), Ghi chú u cầu (nếu có). Khi lựa chọn xong các yếu tố trên, TSV sẽ tiến hành ghi lại để kết thúc nhập thông tin, chuyển tiếp sang giao dịch khác. Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm sốt để các KSV có thể vào kiểm tra và chấp nhận giao dịch. Khi có thơng báo sửa
Nhập YCTS lần 2: Khi có trả lời tra sốt lần 1, tức là khi giao dịch đã được trả lời tra soát với yêu cầu tra soát lần 1 của TSV, có thể xảy ra trường hợp giao dịch này sẽ được đưa vào tra sốt lần 2. Mục đích của tra sốt lần 2 là làm rõ hơn những thông tin về giao dịch lần 1, bao gồm những chứng cứ xác thực hơn để làm rõ giao dịch này trong trường hợp bên TCPHT chưa thỏa mãn với câu trả lời từ TCTTT. Khi cần yêu cầu lần 2, các TSV sẽ vào chức năng tạo yêu cầu lần 2. Khi đó những giao dịch đã trả lời lần 1 sẽ được hiện lên, bao gồm những thông tin cơ bản để xác định giao dịch. Khi tìm được đúng giao dịch cần tra soát, TSV sẽ lựa chọn:
o Mã tra soát lần 2 (theo bảng mã) o Số tiền tra sốt lần 2 (nếu có) o Ghi chú yêu cầu lần 2 (nếu có)
Khi lựa chọn xong các yếu tố trên, TSV ghi lại để kết thúc, chuyển tiếp sang giao dịch khác. Những giao dịch sau sẽ khơng được tiến hành tra sốt lần 2: o Giao dịch đã được trả lời lần 1 với mã thành công (304) hoặc hoàn trả 1
phần tiền (302).
o Giao dịch có ngày tra sốt lần 2 – ngày trả lời lần 1 <=15 ngày làm việc Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm sốt. Khi có thơng báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch
Kiểm sốt các YCTS (chỉ có KSV mới được vào chức năng này)
KSV vào chức năng kiểm soát, tất cả các giao dịch đã được TSV nhập vào nhưng chưa được kiểm soát sẽ hiển thị ra, bao gồm các thông tin như: Tên TSV, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hồn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra sốt lần 2, Số tiền tra sốt lần 2 (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCTTT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. KSV kiểm soát các yếu tố của giao dịch, và chấp nhận ―đúng‖ hoặc ―sai‖ đối với yêu cầu được đưa ra.
o Giao dịch đã được chọn ―sai‖ được chuyển lại để TSV sửa
Sau khi lựa chọn ―đúng‖ hoặc ‗sai‖ xong, KSV sẽ khơng có quyền vào sửa lại những giao dịch này nữa.
Kiểm tra các Trả lời Tra soát
Ngay khi người dùng truy cập vào chức năng này, các giao dịch đã được trả lời đang chờ xử lý sẽ hiện lên bao gồm các thơng tin sau: Ngày u cầu Tra sốt lần 1, Mã tra soát lần 1, Số tiền tra sốt lần 1 (nếu có), Ghi chú u cầu lần 1(nếu có), Ngày Trả lời Tra sốt lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày u cầu Tra sốt lần 2, Mã tra soát lần 2, Số tiền tra soát lần 2 (nếu có), Ghi chú u cầu lần 2(nếu có), Ngày Trả lời Tra sốt lần 2, Mã trả lời lần 2, Số tiền hồn trả lần 2 (nếu có), Ghi chú trả lời lần 2 (nếu có), Tên File attach khi trả lời lần 2 (nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCTTT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Mỗi giao dịch sau khi đã được TCPHT xử lý, người dùng sẽ tích vào nút duyệt, sau đó khơng hiển thị ở hàng đợi nữa (chức năng duyệt chỉ có tác dụng loại giao dịch ra khỏi hàng đợi, giúp TCPHT theo dõi, khơng ảnh hưởng gì đế dữ liệu trả lời của TCTTT)
Lập báo cáo: Các loại báo cáo:
o Bảng kê chi tiết các giao dịch yêu cầu tra soát lần 1 tại TCPHT o Bảng kê chi tiết các giao dịch yêu cầu tra soát lần 2 tại TCPHT o Bảng kê chi tiết các giao dịch được trả lời tra soát lần 1 tại TCPHT o Bảng kê chi tiết các giao dịch được trả lời tra soát lần 2 tại TCPHT o Bảng kê chi tiết các giao dịch tra soát quá hạn tại TCPHT
Các tham số lựa chọn khi lập báo cáo: Từ ngày, đến ngày, TCTTT, Loại báo cáo.
Tại TCTTT
Nhận các yêu cầu tra soát: Ngay khi người dùng truy cập, vào chức năng này, các giao dịch đang chờ trả lời sẽ hiện lên bao gồm các thông tin sau: Ngày Yêu
yêu cầu lần 1(nếu có), Ngày Trả lời Tra soát lần 1, Mã trả lời lần 1, Số tiền hồn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên file kèm theo khi trả lời lần 1 (nếu có), Ngày Yêu cầu Tra soát lần 2, Mã tra soát lần 2, Số tiền tra sốt lần 2 (nếu có), Ghi chú u cầu lần 2(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Mỗi giao dịch sau khi đã được TCTTT chấp nhận tra sốt sẽ được chuyển sang màn hình trả lời của TSV
Nhập TLTS lần 1: Khi TSV vào chức năng này, những giao dịch cần được trả lời lần 1 sẽ hiện lên, bao gồm những thông tin như sau: Số ID giao dịch, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra sốt lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCPHT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Khi tìm được đúng giao dịch cần trả lời tra soát, TSV sẽ lựa chọn:
o Mã trả lời lần 1
o Số tiền hồn trả lần 1 (nếu có) o Ghi chú trả lời lần 1 (nếu có) o Số tham chiếu giao dịch (nếu có)
Khi lựa chọn xong các yếu tố trên, lựa chọn đồng ý trả lời để kết thúc, chuyển tiếp sang giao dịch khác. Những giao dịch sau đây sẽ bị chặn:
o Giao dịch đã có RC=115 nhưng được trả lời lần 1 với mã khác mã 303. o Giao dịch đã bị ghi nợ cho TCTTT (TCTTT không được phép trả lời khi đã
quá hạn).
Tất cả các giao dịch khi đã được TSV trả lời xong sẽ được chuyển sang màn hình kiểm sốt. Khi có thơng báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch.
Nhập TLTS lần 2: Khi TSV vào chức năng trả lời tra sốt lần 2, những thơng tin sau đây của giao dịch sẽ được hiện lên: Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra sốt lần 1 (nếu có), Ghi chú u cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hồn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Số tham chiếu giao dịch (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra sốt lần 2, Số tiền tra sốt (nếu có), Ghi chú u cầu
dịch, Số trace, TCPHT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Khi tìm được đúng giao dịch cần trả lời, TSV sẽ lựa chọn:
o Mã trả lời tra soát lần 2(theo bảng mã) o Số tiền hồn trả lần 2 (nếu có)
o Ghi chú trả lời lần 2 (nếu có) o Số tham chiếu giao dịch (nếu có)
Khi lựa chọn xong các yếu tố trên, TSV lựa chọn đồng ý để kết thúc, chuyển tiếp sang giao dịch khác. Các giao dịch sau sẽ bị chặn, có cảnh báo:
o Giao dịch đã có RC=115 nhưng được trả lời lần 1 với mã khác mã 303. o Giao dịch đã bị ghi nợ cho TCTTT (TCTTT không được phép trả lời khi đã
quá hạn)
Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm sốt. Khi có thơng báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch.
Kiểm soát các TLTS: KSV vào chức năng Kiểm soát, tất cả các giao dịch đã được TSV nhập vào nhưng chưa được kiểm soát sẽ hiển thị ra. Những thông tin sau được hiển thị lên màn hình: Tên TSV, Số ID giao dịch, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hồn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra sốt lần 2, Số tiền tra sốt lần 2 (nếu có), Ghi chú u cầu lần 2(nếu có), Ngày TLTS lần 2, Mã trả lời lần 2, Số tiền hoàn trả lần 2 (nếu có), Ghi chú trả lời lần 2 (nếu có), Tên File attach khi trả lời lần 2 (nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. KSV kiểm soát các yếu tố của giao dịch, lựa chọn đúng hoặc sai. Giao dịch trả lời đã được chọn là đúng sẽ được chuyển về cho bên TCPHT.Giao dịch đã được chọn là sai được chuyển lại để TSV sửa, giao dịch này Ngày TLTS sẽ mất đi.
3.2 Thiết kế Hệ thống