Một số vấn đề liên quan tới kế toán đa ngoại tệ

[Mr Okebab]

Cẩn thận không vi phạm bản quyền đấy các bác ạ!!!

Thân!

 

[hai2hai]

Cẩn thận không vi phạm bản quyền đấy các bác ạ!!!

Thân!

ACCPAC cho phép download trial. Có đầy ở trên website của bác Đại Yukos. Đại Yukos gửi cho hai2hai 2 bộ trial rồi.

Một khi đã cài đặt trial lên thì có thể revert database để tham khảo (chứ làm sao mà làm y chang như nó được)

Hai2Hai hiện đang tham khảo SAP B1, Sage Accounts V12.00, MyOb 14, QuickBook, Peachtree Accounting, và 1 vài ứng dụng có tên tuổi khác nữa (toàn trial cả mà)

 

[hai2hai]

Mình chưa rõ được ý nghĩa (1), các trường hợp áp dụng (2) của các nhóm tỷ giá (Rate Type) được áp dụng như thế nào:

Rate types:
- Monthly average rate (AV)
- Daily spot rate (SP)
- Financial Translation-Average (TA)
- Financial Translation-Current (TR)

 

[ptm0412]

Finished (Kiểu boolean chứ)

Ừ, nhầm (lú lẫn thật)

việc kiểm soát trạng thái hóa đơn ko làm kiểu đó được mà phải viết SQL để check tổng của các phần thanh toán cho hóa đơn đó so với tổng giá trị của hóa đơn.

Check bằng tay hay bằng mã lệnh cũng cần field đó chứ nhỉ? Vì mình nghĩ đưa trạng thái vào 1 field thì xử lý tốt hơn, nhất là khi xử lý cuối kỳ. Nếu check bằng mã lệnh thì không đưa field đó lên màn hình, thế thôi.

Mình giả dụ những trường hợp sau:

1.Trường hợp hoá đơn số 001 trị giá 400USD tỷ giá 16.000 = 6.4tr, hoá đơn 002 trị giá 600USD tỷ giá cho đơn giản cũng là 16.000 = 9.6 tr
Khách hàng thanh toán lần đầu 500EUR cho cả 2 hoá đơn tỷ giá 23.000 = 11.5tr, tỷ giá USD thời điểm này là 16.100
Kế toán thu phải tính tay (hoặc tốt hơn lập 1 bảng chiết tính bằng Excel và in ra làm 1 chứng từ gọi tạm là "căn cứ hạch toán" có ký tên người tính) cho ra kết quả là:
=400 * 16.1 / 23 = 279.13 EUR cho hoá đơn 001, làm phiếu thu dòng thứ nhất.
Còn lại 220.87 EUR làm dòng thứ 2 cho hoá đơn 002

Cái này thì dễ rồi, code lệnh tự động tính và check finished cho hoá đơn thứ nhất, không check hoá đơn 002.

2.Nhưng cũng có trường hợp khách trả chỉ 279.00 EUR theo tỷ giá của nước họ, và tuyên bố hết nợ hoá đơn 001 (thực ra thiếu 0.13 EUR), trường hợp này phải check bằng tay

Vấn đề về sửa chứng từ:
- Khi sửa chứng từ đã có phiếu thu (đủ hoặc chưa đủ), người sửa phải kiểm tra dấu check này.
- Nếu không kiểm tra hoặc kiểm tra sót gây lỗi True -- False thì kế tóan công nợ sẽ phát hiện ra: Tổng bảng kê hoá đơn nợ, không bằng tổng dư nợ của từng khách hàng.
- Nếu Kế toán công nợ không phát hiện, thì kế toán tổng hợp sẽ phát hiện: Tổng bảng kê hoá đơn nợ không bằng tổng sô dư tài khoản 131
- Nếu kế toán tổng hợp không phát hiện, KTT phải phát hiện. (Nếu không thì nghỉ làm việc khác cho xong)

Còn cái chứng từ "căn cứ hạch toán" nêu trên mình nghĩ phải in ra và phải lưu file Excel là cũng có lý do: Để biết rằng hôm qua nhân viên A tính thế này cho con số để hạch toan phiếu thu này, còn năm ngoái nhân viên B tính thế kia cho phiếu thu kia.

 

[hai2hai]

Vấn đề về sửa chứng từ:
- Khi sửa chứng từ đã có phiếu thu (đủ hoặc chưa đủ), người sửa phải kiểm tra dấu check này.
- Nếu không kiểm tra hoặc kiểm tra sót gây lỗi True -- False thì kế tóan công nợ sẽ phát hiện ra: Tổng bảng kê hoá đơn nợ, không bằng tổng dư nợ của từng khách hàng.
- Nếu Kế toán công nợ không phát hiện, thì kế toán tổng hợp sẽ phát hiện: Tổng bảng kê hoá đơn nợ không bằng tổng sô dư tài khoản 131
- Nếu kế toán tổng hợp không phát hiện, KTT phải phát hiện. (Nếu không thì nghỉ làm việc khác cho xong)

- Nếu KTT ko phát hiện ra thì .... phần mềm phải phát hiện ra (Nếu ko thì vứt phần mềm đi mua phần mềm khác)

Nói vui vậy thôi, thông thường 1 hệ thống phần mềm tốt thường sẽ phải có chức năng ra soát lại toàn bộ nghiệp vụ hệ thống (dĩ nhiên là theo logic của nghiệp vụ) để đưa lên những cảnh báo, gợi ý, nhắc nhở nhằm giúp những người làm nghiệp vụ có thể thực hiện tốt các công việc của mình.

Ví dụ, khi theo dõi doanh thu, lãi gộp mà tự nhiên thấy lỗ nặng thì tức là "có vấn đề". Phải có chức năng theo dõi mặt hàng đó từ các chứng từ, xem lịch sử của mặt hàng đó diễn biến thế nào. Và kiểu gì cũng thấy hàng đó bị âm kho liên tục --> giá vốn có thể âm (và được gán = 0 khi bị âm).

Việc check tình trạng chứng từ là thường xuyên phải thực hiện (ví dụ: trạng thái của đơn hàng, tình trang thanh toán của hóa đơn, v.v...)

Việc check tình trạng của chứng từ thì hai2hai ko sử dụng trường boolean đó mà sử dụng SQL để check ở thời điểm đó. Ví dụ: sử dụng method objInvoice.PaymentStatus(). Ở đó, sẽ thực hiện việc kiểm tra tổng tiền thanh toán so với tổng giá trị hóa đơn để biết được 1 trong 4 trạng thái thanh toán của hóa đơn: Đã thanh toán, chưa thanh toán, thanh toán 1 phần, thanh toán vượt. (Không chậm hơn so với việc lấy giá trị của trường Finished kia đâu mà lại có tính tức thời, ko phải cập nhật Finished khi sửa chứng từ).

Việc kết chuyển công nợ hai2hai ko cần dựa vào trường Finished mà sử dụng 1 vài câu SQL là có thể kết chuyển được.

 

[cadafi]

Mình chưa rõ được ý nghĩa, các trường hợp áp dụng của các nhóm tỷ giá (Rate Type) được áp dụng như thế nào:

Đây là một reference option. Khi nói đến tỉ giá thì thường ta phải xác định đây là loại tỷ giá nào, ta đang áp dụng loại tỷ giá nào (giống như khi khấu hao phải xác định xem ta khấu hao theo phương pháp nào ý mà). Trước khi tạo tỷ giá cho loại tiền tệ nào phải setup loại tỳ giá trước và sau đó tham chiếu tỷ giá theo loại (phương pháp xác định tỷ giá) Ví dụ:

Tỷ giá bình quân tháng (Monthly Average Rate - cái này chắc chỉ có vài cty nhà nước xài)
Tỷ giá giao ngay. (Daily Spot - thường được áp dụng).
Tỷ giá chuyển đổi tài chính bình quân (cái này em đang nghiên cứu)
Tỷ giá chuyển đối tài chính hiện hành (cái này em cũng đang nghiên cứu luôn).

 

[cadafi]

To: Anh hai2hai

File đính kèm là Schema của database Accpac. Em gửi anh tham khảo nhé.
Không biết có dịp nào gặp được anh để thỏa lòng mong nhớ đây!

 

[ptm0412]

- Nếu KTT ko phát hiện ra thì .... phần mềm phải phát hiện ra (Nếu ko thì vứt phần mềm đi mua phần mềm khác)

Hai2hai thương KTT nhỉ! Thương không xuể đâu nhé! Chủ yếu trách nhiệm là của con người, PM do con người tạo ra và không bao giờ lường được hết mọi lỗi do người khác tạo ra. Mà bảo đảm 10 em KT thì sai ít nhất 11 kiểu. Mấy Ông/bà KTT phải bằng mọi cách, dùng mọi kinh nghiệm đã có, kết hợp đủ các loại phương pháp để phát hiện mọi sai sót dù chỉ 1 đồng, và 1 đồng sai sót nằm ở đâu. Ấy là mỗi KTT chỉ có từ 1 chục đến 2 chục nhân viên. Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

 

[cadafi]

Hai2hai thương KTT nhỉ! Thương không xuể đâu nhé! Chủ yếu trách nhiệm là của con người, PM do con người tạo ra và không bao giờ lường được hết mọi lỗi do người khác tạo ra. Mà bảo đảm 10 em KT thì sai ít nhất 11 kiểu. Mấy Ông/bà KTT phải bằng mọi cách, dùng mọi kinh nghiệm đã có, kết hợp đủ các loại phương pháp để phát hiện mọi sai sót dù chỉ 1 đồng, và 1 đồng sai sót nằm ở đâu. Ấy là mỗi KTT chỉ có từ 1 chục đến 2 chục nhân viên. Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

Người xưa có câu: Cái gì cũng có cái giá của nó!
Vì vậy mới có các phần mềm lên đến vài triệu, vài chục triệu USD. Không biết khi nào em mới có diễm phúc chiêm ngưỡng một phần mềm như thế!

 

[hai2hai]

Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

Vâng, bên phần mềm biết là ko thể cover hết được mọi sai lầm của con người tạo ra. Nhưng sẽ cố gắng để chỉ ra những sai lầm đó (đến 1 mức có thể).

Làm dâu trăm họ nó khổ thế đấy. Họ sai nhưng họ kêu ca phần mềm của mình làm cho họ làm sai . Giả sử mọi chuyện "đã rồi" mà mình ko hỗ trợ họ thì họ lại bảo "chất lượng dịch vụ kém". Nhưng nếu muốn dịch vụ tốt thì lại chi phí vào đó cao (1 KH ko sao nhưng nhiều KH mà cứ gọi điện hay đi lại liên tục thì chỉ có lỗ vốn - chủ yếu là cái thời gian hỗ trợ nhiều, mà thời gian lại là tiền).

Thế nên, để tránh lỗi của người sử dụng, và khắc phục "hậu quả" do người dùng đem lại (mà vẫn được đánh giá là dịch vụ tốt) thì các nhà làm phần mềm phải nghĩ ra các công cụ hạn chế tối đa các trường hợp người dùng làm lỗi và khắc phục với chi phí thấp nhất những gì đã "chót" xảy ra.

Nhân tiện cái vụ Đa ngoại tệ vừa rồi. Mọi người cứ thử sửa chứng từ, chuyển đi chuyển lại cái tiền tệ giữa VNĐ và USD trên chứng từ. Sao cho 1 con số nó lẻ khi nhân với 1/ExchangeRate. Lúc chuyển lại lại, tự nhiên sẽ thấy con số tiền nó cứ chênh đi 1 vài đồng. Đó là vấn đề mà mọi người sẽ đau đầu khi xử lý đa nguyên tệ.

 

[ptm0412]

Lúc chuyển lại lại, tự nhiên sẽ thấy con số tiền nó cứ chênh đi 1 vài đồng. Đó là vấn đề mà mọi người sẽ đau đầu khi xử lý đa nguyên tệ

Theo mình cứ làm tròn từ 0 đến 2 số lẻ (tuỳ theo). Sau đó thế nào chẳng có chênh lệch tỷ giá, khi xử CLTG từng tờ hoá đơn, xử luôn cái số lẻ , xong chuyện.

Nhắc lại cái field finished (vẫn còn ấm ức!):

Ví dụ: sử dụng method objInvoice.PaymentStatus(). Ở đó, sẽ thực hiện việc kiểm tra tổng tiền thanh toán so với tổng giá trị hóa đơn để biết được 1 trong 4 trạng thái thanh toán của hóa đơn: Đã thanh toán, chưa thanh toán, thanh toán 1 phần, thanh toán vượt. (Không chậm hơn so với việc lấy giá trị của trường Finished kia đâu mà lại có tính tức thời, ko phải cập nhật Finished khi sửa chứng từ).

Vậy có phải Hai2hai vẫn dùng 1 field PaymentStatus không? nếu phải, thì cũng là mở rộng của field Finished từ 2 trạng thái lên 4 trạng thái, đúng không?
Nói "đúng" cái đi mà!

 

[hai2hai]

Vậy có phải Hai2hai vẫn dùng 1 field PaymentStatus không? nếu phải, thì cũng là mở rộng của field Finished từ 2 trạng thái lên 4 trạng thái, đúng không?
Nói "đúng" cái đi mà!

Không dùng fields PaymentStatus, mà PaymentStatus() là 1 method của objInvoice (ko phải thuộc tính)

Trong method đó, sẽ viết dạng như sau

Lấy tổng tiền hóa đơn (InvoiceID) - Tổng tiền thanh toán cho hóa đơn(InvoiceID)

Cái này chỉ 1 câu Select là ra thôi

 

[Nguyễn Duy Tuân]

Chứng từ trả lại hàng nhiều khi (trong thực tế) nó ko giống như chứng từ nhập/xuất hàng (hoặc hóa đơn mua/bán) đâu. Vì thế ko chung nhau trên cùng 1 chứng từ (để ghi âm) được. Nhiều khi có trên chứng từ trả lại hàng bán nhưng có thêm tiền phạt nữa, v.v....

Trên form nhập mua, bán hàng vẫn có thể kết hợp cho trường hợp hàng trả lại, phần lớn các thông tin có thể dùng chung. MYOB v17 em đang dùng cũng làm như vậy. Trong thực thế, mẫu phiếu trả lại hàng, mua, bán, nhập xuất không giống nhau. Vì thế, mặc dù chung một form nhập nhưng cho phép in ra các mẫu chứng từ khác nhau. Việc lập riêng mỗi đặc thù nghiệp vụ một form nó cũng rõ ràng nhưng sẽ mất công thiết kế. Việc kết hợp theo luồng nghiệp vụ, chỉ cần có một lựa chọn "Loại chứng từ" (Mua, Hàng mua trả lại,...) sẽ đỡ mất công hơn. Nếu có phát sinh tiền phạt, hay gì đó thì vẫn cho phép nhập tiếp trong cột "Item" của grid nhưng là nhập giá trị chứ không nhập số lượng. Trong các chứng từ mua, bán em vẫn ch phép nhập mã hàng, số lượng và các phí kèm theo.

Trên các hóa đơn vẫn nên có trường "Giá trị quy đổi" (theo đồng tiền chính), điều này đúng cho cả trường hợp có phiếu thu, chi mà thanh toán trên nhiều ngoại tệ.

Trong sổ nhật ký có thể không cần "Giá trị quy đổi" vì có thể kết hợp [Tỷ giá]*[Số tiền].

 

[hai2hai]

Theo mình cứ làm tròn từ 0 đến 2 số lẻ (tuỳ theo). Sau đó thế nào chẳng có chênh lệch tỷ giá, khi xử CLTG từng tờ hoá đơn, xử luôn cái số lẻ , xong chuyện.

Đơn giá tiền Việt là 20,000VNĐ
Đơn giá $ là 20,000 * 1 /tỷ giá

Quay đi quay lại (chọn cái danh sách tiền tệ trên chứng từ ấy). Thế là Đơn giá nó lẻ ko còn 20,000 như lúc đầu nữa (vì lúc mình chuyển qua USD mình format nó thành ###0.00 mà). Vụ này trên Excel thì nó lưu cả phần lẻ nên ko sao. Trên PM, các ô textbox thì phải cắt đi chứ. Thế là quay đi quay lại cái combo tiền tệ, mọi thứ lẻ linh tinh cả. Đang nghĩ kế để nó giữ nguyên các con số ban đầu. (vì lúc lưu vào Database thì lưu số tiền theo tiền cơ sở chứ có lưu tiền ngoại tệ đâu). Nếu ko nghĩ được cách thì đành mặc lẻ thôi.

 

[hai2hai]

Trên các hóa đơn vẫn nên có trường "Giá trị quy đổi" (theo đồng tiền chính), điều này đúng cho cả trường hợp có phiếu thu, chi mà thanh toán trên nhiều ngoại tệ.

Đúng rồi, cột "Giá trị quy đổi" thì nó chính là các cột giá trị trước kia mà thôi. Mặc định các cột giá trị trên mọi chứng từ là theo đồng tiền cơ sở mà. Nếu ko có cột đó thì lưu giá trị tiền (nào là tiền thuế, nào là tiền CK hóa đơn, nào là tiền phi phí khác, nào là tổng tiền hóa đơn) của hóa đơn vào đâu?

Nhưng Tuân quên mất là việc thanh toán cho 1 hóa đơn thì có thể thanh toán nhiều loại tiền cùng 1 lúc à?

Ví dụ: Tuân bán cho anh 1 phần mềm kế toán A-excel. Giá trị hóa đơn bán hàng là 120$
Anh trả tuân tiền mặt luôn. Nhưng anh chỉ có 100$ thôi, còn lại 20$ anh sẽ trả tiền VND.

Vấn đề là em sẽ phải thiết kế phiếu thu của em để cùng 1 lúc thanh toán được 2 (thậm chí nhiều hơn 2) loại tiền tệ. Nếu em chỉ có 1 cột tiền "Số tiền thanh toán" thì lúc em cộng tổng tiền thanh toán tính sao đây. Nếu thanh toán mà chỉ có 1 loại tiền thôi thì đơn giản quá.

 

[ptm0412]

Trong method đó, sẽ viết dạng như sau
Lấy tổng tiền hóa đơn (InvoiceID) - Tổng tiền thanh toán cho hóa đơn(InvoiceID)
Cái này chỉ 1 câu Select là ra thôi

Hiểu rồi, nghĩa là không phải 1 trường cố định trong table dữ liệu, mà khi cần sẽ gọi ra bằng mã lệnh. Nếu method đó có cấu trúc như kiểu select case sẽ được nhiều trạng thái (4).
Quay lại chuyện số lẻ:

Đơn giá tiền Việt là 20,000VNĐ
Đơn giá $ là 20,000 * 1 /tỷ giá

Mình tưởng rằng khi xuất 1 hoá đơn ngoại tệ, thì đơn gía ngoại tệ phải có trước chứ? Hình dung trình tự nhập chi tiết hoá đơn như sau: (bỏ qua phần header thuộc dữ liệu master)
- mã ItemID (chọn trong 1 list)
- mã tiền tệ CurrID (chọn trong 1 list)
- tỷ giá của loại tiền tệ đó, tự lookup từ ExchangeRateHistory, sửa tay lại nếu cần.
- Gõ Số lượng
- Gõ đơn giá ngoại tệ
- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Nếu hoá đơn tiền việt cũng tương tự, tỷ giá = 1 hiện ra hoặc mờ đi do disable, thành tiền cũng tính tương tự với tỷ giá = 1

Đâu có cái vụ đơn giá 20.000VND, tính ra bao nhiêu tiền ngoại tệ? Chắc đang nói đến thành tiền ngoại tệ (do không được save vào data).

(vì lúc mình chuyển qua USD mình format nó thành ###0.00 mà). Vụ này trên Excel thì nó lưu cả phần lẻ nên ko sao. Trên PM, các ô textbox thì phải cắt đi chứ

Sao thế? thể hiện trên textbox bị cắt đi là do format, lưu lại thế nào là do định nghĩa thuộc tính của trường có bao nhiêu số lẻ. Như trường number trong access và FoxPro có thuộc tính Decimal Place do mình thiết lập khi create table. (Data của ngôn ngữ khác thì không biết).

Đang nghĩ kế để nó giữ nguyên các con số ban đầu. (vì lúc lưu vào Database thì lưu số tiền theo tiền cơ sở chứ có lưu tiền ngoại tệ đâu). Nếu ko nghĩ được cách thì đành mặc lẻ thôi

Nói về sửa dữ liệu thì là hoặc sửa đơn giá (NT), hoặc sửa số lượng, sửa tỷ giá, sửa mã tiền tệ, thì thành tiền VND (cơ sở) ban đầu sẽ phải thay đổi chứ.

Chỉ còn lại vấn đề khi thanh toán bằng các ngoại tệ khác, không phải loại NT trên hoá đơn, lúc này phải chấp nhận 1 mức độ sai số khi quy đổi các ngoại tệ thanh toán thành ngoại tệ ghi hoá đơn, qua trung gian tỷ giá đối với Based Currency (VND). Xem lại bài 16, các thao tác cần xử lý.
Trong mức độ cho phép đó thì hoá đơn đổi trạng thái. Còn tổng ngoại tệ thanh toán không có giá trị (vì 1: nhiều loại tiền tệ, 2: có sai số), chỉ có tổng thành tiền cơ sở (VND) có giá trị dùng để tính CL tỷ giá, lúc này xử luôn số lẻ nếu có của số chênh lệch hoá đơn giữa tổng tiền ghi hoá đơn và tổng tiền Thanh toán (tiền cơ sở, VND). Thế là chấm dứt 1 tờ hoá đơn. Mọi sửa chữa sau đó không cho phép sửa trực tiếp mà phải thực hiện bút toán điều chỉnh. Cada_fi cũng làm thế.

 

[hai2hai]

Quay lại chuyện số lẻ:

Mình tưởng rằng khi xuất 1 hoá đơn ngoại tệ, thì đơn gía ngoại tệ phải có trước chứ? Hình dung trình tự nhập chi tiết hoá đơn như sau: (bỏ qua phần header thuộc dữ liệu master)
- mã ItemID (chọn trong 1 list)
- mã tiền tệ CurrID (chọn trong 1 list)
- tỷ giá của loại tiền tệ đó, tự lookup từ ExchangeRateHistory, sửa tay lại nếu cần.
- Gõ Số lượng
- Gõ đơn giá ngoại tệ
- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Nếu hoá đơn tiền việt cũng tương tự, tỷ giá = 1 hiện ra hoặc mờ đi do disable, thành tiền cũng tính tương tự với tỷ giá = 1

Đâu có cái vụ đơn giá 20.000VND, tính ra bao nhiêu tiền ngoại tệ? Chắc đang nói đến thành tiền ngoại tệ (do không được save vào data).

Đúng rồi, trên danh mục hàng hóa hiện nay ko lưu giá theo ngoại tệ mà chỉ lưu giá theo tiền cơ sở. Thực ra là do mới bổ sung tính năng đa nguyên tệ nên khi thử áp dụng ngoại tệ, lúc chuyển đổi theo tỷ giá thì tự nhiên thấy giá cứ lẻ lung tung. Trên thực tế, chắc giá hàng sẽ ko lẻ như thế vì họ sẽ dùng Giá Cơ sở = Giá NT * Tỷ giá.

Nhưng nếu trên hóa đơn dùng tỷ giá khác với tỷ giá trên danh mục thì Giá bán Cơ sở sẽ ko giống như giá bán ở trên danh mục.

- Gõ đơn giá ngoại tệ --> Thông thường ở bán lẻ, giá bán được nhà quản lý thiết lập sẵn chứ ko cho nhân viên bán hàng sửa giá. Dĩ nhiên, vẫn cho phép sửa giá bán nếu user có quyền sửa.

- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Sao thế? thể hiện trên textbox bị cắt đi là do format, lưu lại thế nào là do định nghĩa thuộc tính của trường có bao nhiêu số lẻ. Như trường number trong access và FoxPro có thuộc tính Decimal Place do mình thiết lập khi create table. (Data của ngôn ngữ khác thì không biết).

Nói về sửa dữ liệu thì là hoặc sửa đơn giá (NT), hoặc sửa số lượng, sửa tỷ giá, sửa mã tiền tệ, thì thành tiền VND (cơ sở) ban đầu sẽ phải thay đổi chứ.

Chỉ còn lại vấn đề khi thanh toán bằng các ngoại tệ khác, không phải loại NT trên hoá đơn, lúc này phải chấp nhận 1 mức độ sai số khi quy đổi các ngoại tệ thanh toán thành ngoại tệ ghi hoá đơn, qua trung gian tỷ giá đối với Based Currency (VND). Xem lại bài 16, các thao tác cần xử lý.
Trong mức độ cho phép đó thì hoá đơn đổi trạng thái. Còn tổng ngoại tệ thanh toán không có giá trị (vì 1: nhiều loại tiền tệ, 2: có sai số), chỉ có tổng thành tiền cơ sở (VND) có giá trị dùng để tính CL tỷ giá, lúc này xử luôn số lẻ nếu có của số chênh lệch hoá đơn giữa tổng tiền ghi hoá đơn và tổng tiền Thanh toán (tiền cơ sở, VND). Thế là chấm dứt 1 tờ hoá đơn. Mọi sửa chữa sau đó không cho phép sửa trực tiếp mà phải thực hiện bút toán điều chỉnh. Cada_fi cũng làm thế.

CSDL lưu ngoại tệ dạng Numeric(14,2) thôi, ko cần lưu dài làm gì. Khi tính toán thì dùng số Double nên nó vẫn lưu số lẻ. Khi hiển thị lên TextBox thì dùng txtFields(CST_...).Text = Format$(dblTotalAmount, strNumericFormat)

Hàm format sẽ làm tròn số luôn trước khi hiện lên textbox.

Khi chọn ngoại tệ khác, nó lại lấy giá trị trên textbox đó (đã bị làm tròn) để quy đổi về giá trị cũ theo tỷ giá của NT trước (và khi đó giá trị đã khác đi vì giá trị trên Textbox đã bị làm tròn, khi nhân với tỷ giá thì ko còn như cũ nữa).

Nói tóm lại, cứ phải làm thì mới nhận ra điều đó.

 

[Nguyễn Duy Tuân]

Khi một trường đóng vai trò là trường số (kiểu Double), theo em nên làm thế này:

Trường đó có 2 property (mọi người hiểu như 2 biến thành viên) là

AsNumber : lưu số lẻ theo phép tính (nguyên bản)
AsText : lưu số sau khi đã format(...) (hình thức thể hiện trên form, không dùng để tính toán)

Như vậy khi cho tham gia vào biểu thức tính toán thì dùng AsNumber để làm, có thể kết hợp hàm Round(AsNumber,nRound) .

 

[ptm0412]

Hàm format sẽ làm tròn số luôn trước khi hiện lên textbox.
...
Nói tóm lại, cứ phải làm thì mới nhận ra điều đó.

Mình không bị điều đó, vì xài Property Textbox.format chứ không dùng hàm format, tại Access và Fox không có hoặc không học tới, --> tầm mắt chỉ tới đó (hii)

 

[hai2hai]

Khi một trường đóng vai trò là trường số (kiểu Double), theo em nên làm thế này:

Trường đó có 2 property (mọi người hiểu như 2 biến thành viên) là

AsNumber : lưu số lẻ theo phép tính (nguyên bản)
AsText : lưu số sau khi đã format(...) (hình thức thể hiện trên form, không dùng để tính toán)

Như vậy khi cho tham gia vào biểu thức tính toán thì dùng AsNumber để làm, có thể kết hợp hàm Round(AsNumber,nRound) .

Yeah, đúng thế. Phải sửa TextBox Control thôi. Nếu ko thì trong phần mềm thêm cả đống biến double, hoặc Database phải thêm cả đống trường thừa.

Hôm rồi thấy có người làm chứng từ có ngoại tệ, khi lưu thì lưu cả tiền cơ sở, tiền ngoại tệ ==> Thêm 1 cơ số trường vào bảng cả master lẫn detail của chứng từ. Lúc load lên form thì ẩn đi 1 cơ số textboxes (cho master) và cột (cho detail grid). Làm thế thì mệt lắm!

Solution tốt nhất: Textbox Control hỗ trợ .Text (lưu theo .DataFormat) và .Value (lưu giá trị thực). Còn khi ghi vào CSDL rồi thì chấp nhận làm tròn số thôi. Không có cách nào cả (vì còn trường hợp 10/3 = 3.333333... nữa mà, làm sao giải quyết được tận gốc)

Mình không bị điều đó, vì xài Property Textbox.format chứ không dùng hàm format, tại Access và Fox không có hoặc không học tới, --> tầm mắt chỉ tới đó (hii)

Yeah, vì VNUNI dùng bộ vnuniSuiteEdit Control tự phát triển nên chưa làm giống Access và Fox. Có lẽ sửa lại bộ control đó để khi .Text thì nó trả về giá trị đúng Format, .Value thì nó trả về đúng giá trị thật của Textbox