2/ Đặc biệt, khi người dùng xóa, sửa ngày chứng từ, thêm, bớt mặt hàng trên chứng từ, sửa số lượng, giá trị của mặt hàng, sửa chứng từ (sorry, sai luật kế toán nhưng ở VN thì đó là chuyện thường xuyên) thì khi đó giá vốn sẽ thế nào (nhất là chứng từ đó nằm trong kỳ đã khóa sổ)?
Khi có thay đổi về dữ liệu nhập hàng thì các giá xuất tính trước đây sẽ bị lệch, phải cho tính lại. Với số lượng phải xử lý là hàng triệu dòng như vậy thì không có cách nào khác ngoài điều khiển tính lại giá xuất bằng lập trình, không thể chỉnh bằng query và macro được, dù là nhập trước xuất trước hay bình quân. Anh đã gặp và chắc anh đã xử lý trường hợp này rồi.
Xin ketoanaccess cho biết việc "tính lại" sẽ thực hiện như thế nào? Tính lại với tất cả hàng hóa cho mọi kho hàng và từ thời điểm nào?
Thêm nữa, việc xóa/sửa chứng từ nó ảnh hưởng tới nhiều vấn đề khác như công nợ, tồn kho (lượng, giá trị), v.v.... Việc "TỰ ĐỘNG TÍNH LẠI" một cách
tức thời sẽ như thế nào
để cho KH ko nhận biết về tốc độ tính toán (vì nếu tính lại từ đầu với mọi mặt hàng, v.v.... thì có lẽ sẽ mất mấy tiếng đồng hồ).
Ghi chú:
1. Tại sao lại phải tự động tính lại? Vì trong thực tế, có rất nhiều người sử dụng phần mềm không hề biết việc sửa/xóa chứng từ nó lại ảnh hưởng thế nào tới những dữ liệu khác. Và sau khi sửa/xóa xong, nếu việc "tính lại" không được thực hiện thì sẽ dẫn tới kết quả một số báo cáo sai --> Họ hiểu là PM bị sai. Chính vì vậy, cần phải TỰ ĐÔNG tính lại một cách tức thời.
2. OK, đồng ý là sẽ tự động tính lại. Nhưng làm thế nào để tính 1 cách nhanh chóng? (nhất là trong môi trường chạy có nhiều users, có nhiều dữ liệu - có những đơn vị như bên VIAMI họ quảng cáo là KH của họ mỗi tháng có 1Gb dữ liệu phát sinh). Đây là vấn đề đặt ra mà ko phải đơn vị làm PM nào cũng làm được
Nếu việc tính BQGB tức thời ngay trên từng chứng từ mà cứ tính theo cách cổ điển là tổng giá trị rồi chia tổng số lượng thì chắc chắn sẽ là quá chậm (nhất là trong trường hợp client chạy online trên Internet). Liệu còn có cách nào tối ưu hơn không? (ketoanaccess học Toán thì chắc chắn sẽ nghĩ ra được cách xử lý trường hợp này giúp anh em)
3/Trong trường hợp bạn làm phiếu thu tiền khách hàng thanh toán, giả sử KH đó thanh toán đợt đó cho toàn bộ 1 chứng từ có số là "HD001" và 1 phần của chứng từ "HD002". Sau đó, người dùng sửa làm tăng/giảm giá trị của chứng từ "HD001" và/hoặc HD002 hoặc xóa 2 chứng từ đó thì mình phải làm thế nào mà ko cần lập trình nhiều mà chương trình có thể cảnh báo được sự quan hệ giữa phiếu thanh toán với chứng từ "HD001" khi người dùng xóa chứng từ "HD001" đó mà ko phải lập trình gì cả
Vấn đề anh nói theo tôi hiểu là thanh toán công nợ theo hóa đơn. Khi khách hàng mang tiền trả thì số tiền đó sẽ được phân bổ trả cho các hóa đơn còn nợ. Nhiều doanh nghiệp muốn theo dõi như vậy để chiết khấu cho khách hàng nếu trả trước thời hạn đã đăng ký hay phạt bằng hình thức nào đó nếu trả quá hạn. Tôi nghĩ là khi đã phân bổ được tổng số tiền thu cho các hóa đơn rồi thì ta có thể thiết kế một số query để cho ra một bảng tổng hợp đối chiếu tổng số tiền trên hóa đơn hiện đang lưu với những đợt đã thanh toán cho hóa đơn đó. Vấn đề này thì không cần sử dụng lập trình.
Vấn đề này bạn hiểu sai ý tôi rồi.
Chính xác là trường hợp "thanh toán công nợ theo hóa đơn" nhưng vấn đề tôi đang đề cập là về việc sau khi tạo phiếu thanh toán cho các chứng từ hóa đơn đó thì sau 1 thời gian, việc sửa/xóa chứng từ gốc làm thay đổi lượng/tiền (hic, lại là vấn đề xóa/sửa chứng từ) sẽ như thế nào nếu đã có chứng từ phái sinh. Cụ thể là:
Hóa đơn H001 (chứng từ dẫn xuất - hay còn gọi là chứng từ gốc của chứng từ phái sinh) có liên quan tới 2 phiếu thu PC001, PC002 (chứng từ phái sinh)
Vậy khi ta quay lại sửa (phần dòng chứng từ)/xóa hóa đơn H001 đi thì vấn đề gì xảy ra?
Trong 1 hệ thống,
ko chỉ có 2 chứng từ có liên quan lẫn nhau mà có hàng loạt các chứng từ có "dây mơ dễ má" với nhau. Vậy khi sửa/xóa 1 trong các chứng từ đó (cả dẫn xuất và phái sinh) thì vấn đề gì xảy ra? Liệu có phải lập trình không hay chỉ viết query (ở các methods Invoice.Save() hoặc Invoice.Delete() chẳng hạn). Ở đây ko nói chuyện không được sửa/xóa chứng từ nhé.
Tôi nghĩ là khi đã phân bổ được tổng số tiền thu cho các hóa đơn rồi thì ta có thể thiết kế một số query để cho ra một bảng tổng hợp đối chiếu tổng số tiền trên hóa đơn hiện đang lưu với những đợt đã thanh toán cho hóa đơn đó. Vấn đề này thì không cần sử dụng lập trình.
Kể cả là như trên thì theo tôi nghĩ cũng ko đơn giản như vậy, trên màn hình chi tiết thanh toán, KH có thể chọn rồi thay đổi những hóa đơn thanh toán theo ý thích của họ.
Ví dụ: Khi tạo phiếu TT với số tiền 5tr VNĐ, họ chọn hóa đơn HH001, sau đó họ chọn HH002, v.v.... Một phiếu TT có thể thanh toán cho 1 hoặc nhiều hóa đơn (và về lý thuyết thì không nhất phải thanh toán hết cho những hóa đơn đó). Dĩ nhiên làm gì thì cũng phải SQL cả thôi nhưng ở đây tôi nói đến tính tinh tế trong việc xử lý khi nhập liệu (KH - mà cụ thể là những người test SP bên tớ họ không thích nhập theo thứ tự hay nghiệp vụ nào đâu. Họ sẽ test kiểu ... làm thế nào để có thể gây ra lỗi nhất để đến khi SP tới tay KH cuối cùng thì sẽ ko sợ lỗi nữa). Sau khi chọn các hóa đơn cần thanh toán, thay đổi hóa đơn cần thanh toán thì việc cần phải biết trạng thái thanh toán của hóa đơn cũng là 1 vấn đề. Việc theo dõi trạng thái thanh toán của các hóa đơn đó ngay trên chứng từ (lúc mở hóa đơn) như thế nào?
Trên đây tôi chỉ nêu ra ý kiến có thể giải quyết một số vấn đề anh đặt ra bằng query không phải lập trình, chưa có cái gì cụ thể hết. Muốn cụ thể phải mô tả chi tiết và có một file mdb với một số dữ liệu minh họa. Tôi đã thử giải quyết nhưng vấn đề trên nhưng chỉ làm cho người khác xài. Trình bày lại để người đọc nắm thì cần phải có thời gian nhiều hơn.
Không cần trình bày quá chi tiết dạng viết sách, chỉ cần nói về hướng là OK rồi.
Nói tóm lại, khi tạo ra 1 phần mềm dùng cho mọi doanh nghiệp, bao giờ ta cũng phải nghĩ đến mọi tình huống xảy ra, vét cạn mọi trường hợp (nhất là vụ sửa/xóa chứng từ - phải tính cả những trường hợp người sử dụng không hề hiểu rõ nghiệp vụ mà họ chỉ biết nhập/sửa chứng từ và lên xem báo cáo thôi). Chính vì vậy, ở một thời điểm nào đó, có thể 1 phần mềm chưa đáp ứng hết mọi tình huống xảy ra, chưa có nhiều tính năng thuận tiện nhưng để có 1 phần mềm tốt thì hàng ngày những người làm PM phải liên tục trau truốt, căn ke tới từng ly, từng tý một liên quan tới sự thuận lợi trong sử dụng, nâng cao tính quản trị có ở mọi nơi trong chương trình, thậm chí thay đổi lại 1 vài tính năng chính của sản phẩm để SP ngày 1 tiến bộ. Đặc biệt, với một số nghiệp vụ cơ bản như tính giá vốn, giá thành, kết chuyển, chuyển kỳ, tra cứu tồn,... thì ngoài tính chính xác ra, tốc độ cũng là điều đáng để đề cập. Có người nói với tôi, trước kia SP của em tính giá vốn, tính giá thành tới vài chục phút, bây giờ em ngồi làm lại theo phương án mới chỉ tính theo giây. Đó chính là điều mà mình gửi nhắn tới các bạn: LIÊN TỤC PHÁT TRIỂN