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

[hai2hai]

Giới thiệu:

Trong quá trình kinh doanh thương mại, đặc biệt trong bối cảnh môi trường hợp tác kinh tế mang tính toàn cầu thì vấn đề "đa ngoại tệ" trở thành 1 bài toán bức xúc về quản lý và có nhu cầu khá lớn đối với các ứng dụng quản lý.

Ở đó, tại một công ty có thể có các giao dịch kinh tế phát sinh (như: báo giá, hợp đồng, đơn đặt hàng (mua và bán), hóa đơn mua/bán hàng...) được thể hiện theo các loại ngoại tệ khác nhau (mỗi giao dịch được thực hiện theo 1 loại ngoại tệ). Việc thanh toán cho các hợp đồng, hóa đơn mua/bán hàng cũng sẽ đa dạng với các trường hợp sau:

Trường hợp 1: Thanh toán cho 1 hóa đơn
a) Sử dụng loại ngoại tệ trên hóa đơn để thanh toán (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán cũng bằng USD)

b) Sử dụng loại ngoại tệ khác để thanh toán cho hóa đơn (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán bằng EUR HOẶC VND...)

c) Sử dụng 2 (hoặc nhiều hơn 2) loại ngoại tệ để thanh toán (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán bằng EUR VÀ VND...)

Trường hợp 2: Thanh toán cho 2 hoặc nhiều hơn 2 hóa đơn cùng 1 lúc

Ví dụ: Có 2 hóa đơn, hóa đơn 1 thể hiện tiền USD, hóa đơn 2 thể hiện tiền EUR

a) Sử dụng loại ngoại tệ tương ứng với từng hóa đơn
Ví dụ: Sử dụng 2 loại ngoại tệ tương ứng là USD và EUR để thanh toán cho từng hóa đơn (trên cùng 1 phiếu thu/chi)

b) Sử dụng 1 loại ngoại tệ để thanh toán cho cả 2 hóa đơn trên
Ví dụ: Có thể sử dụng hoặc USD hoặc EUR hoặc thậm chí đồng tiền cơ sở VND

c) Sử dụng nhiều loại ngoại tệ (kể cả ngoại tệ ko tương ứng với hóa đơn) để thanh toán
Ví dụ: Có thể sử dụng VND và YEN để thanh toán cho 2 hóa đơn trên

Bài toán liên quan tới đa nguyên tệ:

1. Thiết kế phiếu thu, phiếu chi cho phù hợp với các trường hợp trên (Chú ý các giá trị liên quan tới hóa đơn như tổng giá trị, đã thanh toán, chiết khấu thanh toán, tiền thanh toán và phần tổng tiền thanh toán ở dưới chứng từ trên các phiếu thu, phiếu chi)
2. Công nợ được theo dõi theo nhiều loại ngoại tệ (Chú ý: Dư đầu kỳ, cuối kỳ, phát sinh tăng, phát sinh giảm của từng đối tượng công nợ đều liên quan tới ngoại tệ. Ngoài ra, còn có báo cáo theo 1 loại ngoại tệ đã quy đổi để báo cáo cho đơn vị ở nước quản lý)
3. Các quỹ tiền mặt, tiền gửi tương ứng (111,112) (Cái này thì dễ rồi)
4. Đánh giá chênh lệch tỷ giá (giữa thời điểm hóa đơn và thời điểm thanh toán). Cái này thì kế toán nhà ta quen cả rồi.

Mọi người thử xem xét và đưa ra các tình huống khác, rồi trao đổi các giải pháp ở đây nhé.

Cheers!

 

[ptm0412]

Xin bàn trước về Database:
1. Trong dữ liệu hàng ngày thêm 1 trường mã Tiền tệ, 1 trường tỷ giá, 1 trường số tiền NT, 3 trường này sẽ xuất hiện trên form bán hàng (Xuất HĐ) và form thu tiền (111 và 112).
2. Trong table công nợ thêm 1 trường mã Tiền tệ và 2 trường số dư ĐầuKỳ, số dư CuốiKỳ bằng ngoại tệ.
3. trong table danh mục TK cũng thêm 1 trường mã Tiền tệ, số dư ĐK NT, cuối kỳ NT
3. tất nhiên là thêm 1 table Danh mục tiền tệ trong đó có cả VND và là Master cho mấy table trên.

Có các trường này, tôi nghĩ công việc sẽ bớt suy nghĩ rất nhiều.
Nguyên tắc là quy về 1 đơn vị tiền tệ chuẩn (có thể là VND), tỷ giá cũng là quy về đơn vị chuẩn này.
Nhưng bớt rồi không phải là hết chuyện, để nghĩ tiếp.

 

[hai2hai]

Xin bàn trước về Database:
1. Trong dữ liệu hàng ngày thêm 1 trường mã Tiền tệ, 1 trường tỷ giá, 1 trường số tiền NT, 3 trường này sẽ xuất hiện trên form bán hàng (Xuất HĐ) và form thu tiền (111 và 112).

Chỉ cần 2 trường:

- CurrencyID
- ExchageRate <-- trường này sẽ lấy từ bảng "ExchangeRate History" dựa trên ngày chứng từ và ngày lịch sử.

Trên hóa đơn bán hàng, có nhiều con số tiền đều phải thể hiện theo theo loại ngoại tệ đã chọn (đơn giá, giảm giá, chiết khấu, thuế GTGT, các giá trị khác, tổng tiền hàng, tổng tiền hóa đơn, số tiền thanh toán (trường hợp thanh toán ngay)). Vì thế không cần trường số tiền ngoại tệ (vì 1 trường đó thì ko đủ). Khi lưu vào CSDL, ta vẫn lưu như bình thường, chỉ cần kèm thêm 2 trường ở trên. Lúc hiển thị thì chỉ cần lấy các giá trị tiền trên hóa đơn (theo đồng tiền cơ sở) * tỷ giá (và format theo từng loại ngoại tệ)

Về phiếu thu, phiếu chi: Mọi người chú ý là sẽ thanh toán chi tiết cho nhiều chứng từ trên cùng 1 phiếu thu/chi (có thể mỗi dòng 1 loại ngoại tệ khác nhau). Vì thế, ngoài phần header của phiếu thu, phiếu chi, còn phải thể hiện ngoại tệ trên từng dòng chứng từ nữa. (Đọc kỹ lại các trường hợp nêu ở #1)

 

[ptm0412]

Xin nói rõ lại là 3 trường thêm vào, không kể 1 trường "số tiền" có sẵn, nay gọi lại tên là "số tiền theo đơn vị TT quy chuẩn".
Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất? khi người khách hàng trả, họ có thể trả bằng 1 hay nhiều loại NT, giống hoặc không giống trên hoá đơn, nhưng hoá đơn chỉ có 1 loại tiền tệ.

Hơn nữa các khoản chiết khấu, giảm giá, chỉ nằm trong hợp đồng, không nhất thiết ghi vào hoá đơn.
nếu bắt buộc, thì chỉ ghi vào 1 trường discountRate, phần còn lại (phải thanh toán) sẽ là tính toán trên đơn giá, số lượng, DiscountRate ra kết quả không cần tách ra.

 

[cadafi]

Về phiếu thu, phiếu chi: Mọi người chú ý là sẽ thanh toán chi tiết cho nhiều chứng từ trên cùng 1 phiếu thu/chi (có thể mỗi dòng 1 loại ngoại tệ khác nhau). Vì thế, ngoài phần header của phiếu thu, phiếu chi, còn phải thể hiện ngoại tệ trên từng dòng chứng từ nữa. (Đọc kỹ lại các trường hợp nêu ở #1)

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Như phần Mềm ACCPAC rất hay về mảng Multicurrency tuy nhiên nó cũng chỉ cho hạch toán tương ứng một nghiệp vụ bên module con (thu/Chi, công nợ) là một loại tiền tệ mà thôi. Nếu muốn hạch toán nhiều loại ngoại tệ thì phải tách ra làm nhiều nghiệp vụ tương ứng.

Ps: đang tìm lại cái schema database của ACCPAC, tìm xong sẽ gửi anh xem thử nhé!

 

[ptm0412]

ExchageRate <-- trường này sẽ lấy từ bảng "ExchangeRate History" dựa trên ngày chứng từ và ngày lịch sử.

Ý tưởng này có vẻ hay ở chỗ tổ chức CSDL tốt hơn, nhưng không hẳn là tốt nhất. Vì theo hợp đồng mua bán, 2 bên đồng ý sẽ lấy tỷ giá cuả 1 tổ chức tín dụng nào đó (ngân hàng chẳng hạn) tại thời điểm nào đó làm tỷ giá chấp nhận thanh toán. Nếu trong ngày thu tiền của 2 khách hàng khác nhau, KH thứ nhất thoả thuận lấy tỷ giá của ngân hàng A, KH thứ 2 lấy tỷ giá của ngân hàng B, thì dữ liệu ghi vào ExchangeRateHistory là tỷ giá nào?

 

[hai2hai]

Ý tưởng này có vẻ hay ở chỗ tổ chức CSDL tốt hơn, nhưng không hẳn là tốt nhất. Vì theo hợp đồng mua bán, 2 bên đồng ý sẽ lấy tỷ giá cuả 1 tổ chức tín dụng nào đó (ngân hàng chẳng hạn) tại thời điểm nào đó làm tỷ giá chấp nhận thanh toán. Nếu trong ngày thu tiền của 2 khách hàng khác nhau, KH thứ nhất thoả thuận lấy tỷ giá của ngân hàng A, KH thứ 2 lấy tỷ giá của ngân hàng B, thì dữ liệu ghi vào ExchangeRateHistory là tỷ giá nào?

Giá trị "Exchange Rate" lấy mặc định từ ExchangeRateHistory, sau đó cho sửa lại đúng ở thời điểm giao dịch mà (tức là vẫn có trường Exchange Rate trên chứng từ). Nhiều khi tỷ giá ko thay đổi mà cứ phải nhập đi nhập lại. Về sau, có chức ExchangeRateHistory tự động cập nhật biến động tỷ giá từ những nơi mà Ngân hàng công bố (Website,...). (hiện nay có nhiều nơi đã làm như thế rồi)

 

[hai2hai]

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Như phần Mềm ACCPAC rất hay về mảng Multicurrency tuy nhiên nó cũng chỉ cho hạch toán tương ứng một nghiệp vụ bên module con (thu/Chi, công nợ) là một loại tiền tệ mà thôi. Nếu muốn hạch toán nhiều loại ngoại tệ thì phải tách ra làm nhiều nghiệp vụ tương ứng.

Ps: đang tìm lại cái schema database của ACCPAC, tìm xong sẽ gửi anh xem thử nhé!

Cố gắng tìm schema database của ACCPAC nhé. Đúng là các PM nước ngoài nhiều khi chưa chắc đã có.

Về bản chất, phân thân của phiếu thu/chi phải theo 1 loại ngoại tệ duy nhất mà thôi.
Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

Tuy nhiên, phần chi tiết thanh toán thì vẫn phải đa ngoại tệ (phải hiển thị thêm cột nữa là đồng tiền thanh toán chính và chỉ lấy tổng tiền theo cột đó)

Tại sao lại có chuyện trả tiền bằng nhiều loại tiền tệ:

Ví dụ: Khi 1 khách hàng đến trung tâm thương mại. Họ mua 1 mặt hàng giá 120$. Trong túi của họ chỉ có 100$, còn lại là tiền Việt. Họ sẽ trả tiền 100$ và số 20$ lẻ còn lại họ trả bằng tiền việt (tức là cty thu vừa tiền $, vừa tiền việt). Chuyện này là ko hiếm.

 

[ptm0412]

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Phần thu tiền Khách hàng rõ ràng là phải tách ra từng dòng cho từng loại ngoại tệ rồi, không bàn cãi. Xử lý dữ liệu là máy làm nên càng rõ ràng càng tốt.
Còn về báo cáo các loại:
- phiếu thu chi ghi chi tiết theo từng ngoại tệ, nhưng tổng tiền tính theo đơn vị quy chuẩn.
- báo cáo tài khoản KT, báo cáo công nợ, bảng cân đối PS…. quy hết về đơn vị tiền tệ chuẩn.
Chỉ có bảng đối chiếu công nợ và báo cáo chi tiết công nợ từng KH mới chi tiết đến loại ngoại tệ, nhưng kết số dư theo tiền tệ chuẩn phải bằng số dư của TK công nợ Kế toán.

Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

vậy nên trường số tiền theo đơn vị tiền tệ chuẩn vẫn còn cần thiết.

 

[hai2hai]

Xin nói rõ lại là 3 trường thêm vào, không kể 1 trường "số tiền" có sẵn, nay gọi lại tên là "số tiền theo đơn vị TT quy chuẩn".
Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất? khi người khách hàng trả, họ có thể trả bằng 1 hay nhiều loại NT, giống hoặc không giống trên hoá đơn, nhưng hoá đơn chỉ có 1 loại tiền tệ.

Hơn nữa các khoản chiết khấu, giảm giá, chỉ nằm trong hợp đồng, không nhất thiết ghi vào hoá đơn.
nếu bắt buộc, thì chỉ ghi vào 1 trường discountRate, phần còn lại (phải thanh toán) sẽ là tính toán trên đơn giá, số lượng, DiscountRate ra kết quả không cần tách ra.

- Chiết khấu, giảm giá được ghi ngay trên hóa đơn bán hàng (trên màn hình hóa đơn bán hàng thì đúng hơn, in ra thì có thể ko cần). Tiền thuế (GTGT,...) thì phải hiển thị theo đúng loại ngoại tệ.

- Về việc: Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất?

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Tóm lại: Ở đâu cũng cho cái CurrencyID và ExchangeRate, các con số, giá trị vẫn giữ nguyên. Muốn hiển thị theo đồng tiền nào thì chỉ cần Giá trị * ExchangeRate

Ví dụ:

CurrencyID| CurrencyCode | ExchageRate
1 | VND | 1
2 | USD | 1/16,500
3 | EUR | 1/23,000

Trên tất cả các chứng từ, để hiển thị mọi giá trị có mặt trên chứng từ thì chỉ cần lấy Giá trị * ExchageRate của từng loại NT tương ứng. Nếu chọn NT là VND thì:

Số tiền (VND) = Giá trị (Tiền cơ sở) * 1 (vẫn là chính nó nếu VND là tiền cơ sở)

Khi làm các báo cáo theo NT, chỉ cần lấy các con số từ các chứng từ * ExchageRate (có trên chứng từ).

Về bản chất, phần thân của phiếu thu/chi phải theo 1 loại ngoại tệ duy nhất mà thôi.
Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

vậy nên trường số tiền theo đơn vị tiền tệ chuẩn vẫn còn cần thiết.

Chính xác là chỉ cần lưu số tiền theo đơn vị tiền tệ cơ sở (Ví dụ: VND), rồi cứ nhân với ExchageRate của NT chính thức (duy nhất) trên phiếu thu/chi (thường là ngoại tệ của hóa đơn thứ nhất hoặc hóa đơn có giá trị lớn nhất, hoặc theo đồng tiền cơ sở) mặc cho phần chi tiết thanh toán có thể theo ngoại tệ gì.

Xin bàn trước về Database:
2. Trong table công nợ thêm 1 trường mã Tiền tệ và 2 trường số dư ĐầuKỳ, số dư CuốiKỳ bằng ngoại tệ.

Đúng rồi. Việc kết chuyển số dư công nợ phải theo từng loại ngoại tệ. Vấn đề này sẽ làm cho việc kết chuyển sẽ chậm đi so với khi ko quản lý theo ngoại tệ.

 

[ptm0412]

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Sure! Mình muốn nói thế, nhưng tại bài trên Hải nói chỉ 1 trường số tiền ngoại tệ là không đủ! Chắc hiểu nhầm rồi.

 

[cadafi]

- Về việc: Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất?

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Tóm lại: Ở đâu cũng cho cái CurrencyID và ExchangeRate, các con số, giá trị vẫn giữ nguyên. Muốn hiển thị theo đồng tiền nào thì chỉ cần Giá trị * ExchangeRate

Ví dụ:

CurrencyCode | ExchageRate
VND | 1
USD | 1/16,500
EUR | 1/23,000

Trên tất cả các chứng từ, để hiển thị mọi giá trị có mặt trên chứng từ thì chỉ cần lấy Giá trị * ExchageRate của từng loại NT tương ứng.

Khi làm các báo cáo theo NT, chỉ cần lấy các con số từ các chứng từ * ExchageRate.
Chính xác là chỉ cần số tiền theo đơn vị tiền tệ cơ sở (Ví dụ: VND), rồi cứ nhân với ExchageRate của NT chính thức trên phiếu thu/chi

Em kết cái cách này đấy anh hai2hai, đây cũng là cách mà ACCPAC làm đấy.

 

[hai2hai]

Em kết cái cách này đấy anh hai2hai, đây cũng là cách mà ACCPAC làm đấy.

Mình đã phải mất 1 hôm ngồi đọc lại sách SAP R3 về FI đã từng học từ lâu, tham khảo thêm SAP B1 và 1 số sản phẩm nước ngoài khác. Tuy nhiên, phải làm đơn giản hóa nó đi vì nếu phức tạp hóa sợ ko release được sản phẩm đúng hạn

Mình nghĩ chắc sẽ còn những trường hợp khác mà chưa gặp phải. Cũng mong trao đổi thêm với mọi người để những người biết rồi thì biết thêm nữa, những người chưa biết thì có cơ hội tìm hiểu.

Ngoài bài toán tính giá vốn tức thời (đặc biệt trong trường hợp dữ liệu lớn, trường hợp sửa/xóa chứng từ sẽ xảy ra rất nhiều trường hợp), bài toán "đa ngoại tệ", về sau mình sẽ giới thiệu các vấn đề, trường hợp liên quan tới bài toán "đa đơn vị tính" (nhất là trong những trường hợp lắp ráp tháo dỡ, sản xuất).

 

[ptm0412]

Nhân nói đến chủ đề cũ về giá vốn tức thời, ở chủ đề này cũng phải quan tâm vấn đề làm tròn số khi lấy số tiền cơ sở nhân tỷ giá (theo thí dụ của Hải thì là phép chia vì là nhân với 1/16.000), nếu không khéo sẽ còn dư nợ 1, 2 cents

 

[hai2hai]

Nhân nói đến chủ đề cũ về giá vốn tức thời, ở chủ đề này cũng phải quan tâm vấn đề làm tròn số khi lấy số tiền cơ sở nhân tỷ giá (theo thí dụ của Hải thì là phép chia vì là nhân với 1/16.000), nếu không khéo sẽ còn dư nợ 1, 2 cents

Đúng rồi, ở danh mục tiền tệ, phải có lựa chọn định dạng format cho từng loại tiền tệ. Chính vì suy nghĩ 1 cách tổng quát, bao hàm trường hợp đồng tiền cơ sở không phải là VND mà là các ngoại tệ khác nên lần trước khi tính giá vốn mới nhắc tới chuyện làm tròn số như thế nào cho đúng.

Ví dụ: VND thì làm tròn tới hàng đơn vị và có format như sau (#,##0), USD hoặc các ngoại tệ khác thì làm tròn tới n dấu thập phân và có forrmat như sau (#,##0.00). Việc thống nhất định dạng và làm tròn (thông thường 2 cái đó đi cùng với nhau) phải được thống nhất cho từng ngoại tệ trên toàn chương trình.

Ví dụ:

Khi hiển thị số tiền theo ngoại tệ, ta sẽ làm như sau:

ExchangeRate = objCurrency.ExchangeRate(CurrencyID)
'// Trường hợp CurrencyID là BasedCurrency (Tức là có ExchangeRate =1) thì không cho phép nhập ExchangeRate trên màn hình chứng từ nữa.

strCurrencyFormat = objCurrency.NumberFormat
curSymbol = objCurrency.Symbol '// đ, $, ... <-- Cái này là biểu tượng của đồng tiền, được dùng khi hiển thị số tiền bằng chữ hoặc hiển thị biểu tượng bên cạnh các con số tiền.

....
txtFields(CST_FLD_MASTER_TOTAL_AMOUNT).Text = Format$(dblTotalAmount * 1/ExchangeRate, strCurrencyFormat)

'// ExchangeRate để là số to cũng được, trong code ra có thể dùng * 1 / ExchangeRate

Khi save vào CSDL thì ta lại:

dblTotalAmount = txtFields(CST_FLD_MASTER_TOTAL_AMOUNT).Text * ExchangeRate

...
objInvoice.TotalAmount = Format$(dblTotalAmount, strBasedCurrencyFormat)
...
if Not objInvoice.Insert() Then Goto PROC_DONE
...

Phần chi tiết chứng từ ta cũng phải chuyển đổi như vậy để save chứng từ.


Mọi người thử nghĩ thêm tới các trường hợp sau khi đang nhập liệu:

Trường hợp 1: Thay đổi loại tiền tệ (Chọn từ ComboBox) khi đang thêm mới chứng từ (ví dụ hóa đơn bán hàng). Khi đó các giá trị trên dòng chứng từ (đơn giá, thành tiền,...), các giá trị ở phần tổng tiền sẽ thay đổi như thế nào?

Trường hợp 2: Cũng là việc thay đổi ngoại tệ (Chọn từ ComboBox) nhưng ko phải ở trường hợp thêm mới mà là ở trường hợp đang sửa chứng từ. Đặc biệt sửa trong trường hợp hóa đơn đã thanh toán và hóa đơn chưa thanh toán (hoặc thanh toán 1 phần)

Mọi người sẽ thấy việc sửa chứng từ ngoài ảnh hưởng tới giá vốn, giá trị hàng tồn kho, số lượng hàng tồn kho thì nó còn ảnh hưởng rất nhiều tới các yếu tố khác nữa (ví dụ hóa đơn đã thanh toán bị sửa lại). Thế mà các kế toán nhà ta liên tục sửa chứng từ đó

 

[ptm0412]

Đang nghĩ các trường hợp thanh toán ở bài 1, gần ra; Hải nhanh quá đặt thêm vấn đề mới nữa.

Nói tiếp về Database:
Để theo dõi công nợ khách hàng cho rõ ràng trong trường hợp đồng tiền thanh toán khác với đồng tiền trên hoá đơn và mở rộng ra thanh toán 1 lần nhiều loại tiền tệ và hơn nữa là cho nhiều tờ hoá đơn:
- trong table MainData thu chi sẽ cần 1 field Ref_Invoice là hoá đơn liên quan. Thí dụ trả tiền 200$ cho hoá đơn 001, 100EUR cho hoá đơn 001, 300GBP cho hoá đơn 002
- tương ứng trong table công nợ sẽ có field Ref_Invoice cho biết dư nợ từng tờ hoá đơn, thêm vào các field có sẵn: loại ngoại tệ, tỷ giá và số tiền quy chuẩn.
- table công nợ cần thêm 1 field Finished kiểu Binary để kiểm soát hoá đơn đã thanh toán hết hay chưa.

Như vậy khi KH thanh toán sẽ phải tách ra theo hoá đơn, mỗi hoá đơn bao nhiêu tiền, loại tiền tệ nào, tỷ giá bao nhiêu. Căn cứ vào đó ngoài việc hạch toán cấn trừ tài khoản, còn phải cấn trừ chi tiết công nợ theo hoá đơn.

Công việc phải xử lý:
1- Nếu đồng tiền thanh toán khác với đồng tiền trên hoá đơn, phải so sánh tỷ giá 2 đồng tiền với đồng tiền chuẩn là BasedCurrency. Để biết giả sử với 220 EUR đã trừ hết nợ tờ hoá đơn 480USD hay chưa, dù cho 220EUR nhân tỷ giá quy đổi ra BasedCurrency có thể đã dư hoá đơn rồi.
Nếu đồng tiền thanh toán là bao nhiêu loại, phải thực hiện bằng ấy lần.
2- Khi biết rằng 220EUR chính xác bằng 480USD (mức độ chính xác do người dùng đặt), sẽ phải check vào field Finished (kiểu binary, kiểm soát bằng checkbox) nhằm đánh dấu hoá đơn đã thanh toán xong.
3- Cuối kỳ: Trong bảng table công nợ:
a. Lọc những hoá đơn đã check field Finished để tính chênh lệch tỷ giá
b. Lọc những hoá đơn chưa check chuyển số dư sang kỳ sau.

Không biết còn gì nữa không, (chưa nói đến sửa chứng từ). Mà cũng nên khoá những hoá đơn đã check Finished lại không cho sửa. Muốn sửa phải làm bút toán điều chỉnh riêng và phải có Phiếu đề nghị điều chỉnh (cho sợ đừng làm sai).

 

[Nguyễn Duy Tuân]

Em thoae luận sơ sơ thế này.

Trước tiên cần một "Danh mục tiền tệ" có cấu trúc:
|Mã tiền| Tên, diễn giải|Tài khoản hạch toán| Tỷ giá hiện thời| Đơn vị làm tròn|

(*) Trên các chứng từ có thêm 3 trường: Loại tiền, Tỷ giá, một trường Giá trị quy đổi (ra đồng tiền chính).
Trong các sổ nhật ký, có thêm 4 cột: Số tiền, Loại tiền, Tỷ giá, Tiền quy đổi (theo laọi đồng tiền chính - nội tệ).

(*) Với mẫu phiếu thu, chi có thể vừa thanh toán bằng ngoại tệ (các loại:USD, UR,...), vừa nội tệ, ngoài các thông tin cơ bản của một chứng từ thì cần có một Grid/Table thể hiện việc hạch toán chi tiết:

|Mã chứng từ|Trạng thái|Diễn giải|Chiết khấu|Nợ còn phải trả|Thanh toán|Loại tiền|Tỷ giá| Tài khoản đối ứng|

(*) Nếu là Phiếu thu, căn cứ vào loại tiền-->Tài khoản ghi Nợ; Tài khoản đối ứng ghi Có.

(*) Nếu là Phiếu chi, căn cứ vào loại tiền-->Tài khoản ghi Có; Tài khoản đối ứng ghi Nợ.

Trong các chứng từ, nếu vào số âm (-) sẽ định khoản đảo.

(*) Trong các chứng từ có trường "Giá trị quy đổi"

(*) Khi lập báo cáo, cho phép chọn loại đồng tiền để báo cáo = Tiền quy đổi/Tỷ giá.

(*) Vấn đề hàng mua, hàng bán bị trả lại. Làm theo trình tự:
+ Lập phếu điều chỉnh gửi cho bên bán
+ Căn cứ vào sự chấp thuận của bên bán thông qua chứng từ chấp nhận điều chỉnh (Credit Note), cần chia ra làm các trường hợp:

+ Điều chỉnh kho và giảm trừ công nợ
+ Điều chỉnh kho và giả lại tiền
+ Trả lại tiền không thay đổi kho
+...

Lập phiếu điều chỉnh (Credit Note) trong phần mềm, em thường cho nhập trong chính màn hình mua, bán nhưng vào số liệu (số lượng hàng nếu liên quan tới kho) là âm, việc xác định tài khoản giảm trừ doanh thu hay giảm trừ kho hay giá vốn sẽ lấy từ bảng danh mục hàng hóa. Trong danh mục hàng hóa em thường setup các tài khoản cho mỗi hàng hóa luôn (Hàng tồn kho, Giá vốn, Hàng bán bị trả lại,...)

Trong trường hợp chênh lệch tỷ giá, giá trị chênh lệch sẽ được định khoản theo thông tư hiện hành.

Vẫn theo luật, giá trị âm thì định khoản đảo.

Mời mọi người thảo luận tiếp!

 

[hai2hai]

(*) Trên các chứng từ có thêm 3 trường: Loại tiền, Tỷ giá, một trường Giá trị quy đổi (ra đồng tiền chính).
Trong các sổ nhật ký, có thêm 4 cột: Số tiền, Loại tiền, Tỷ giá, Tiền quy đổi (theo laọi đồng tiền chính - nội tệ).

Có nhất thiết có cột "Tiền quy đổi" trong CSDL không?

Cột "Tiền quy đổi" = Số tiền * Tỷ giá, khi cần tính toán thì lấy 2 trường đó cho chính xác, hạn chế việc tạo thêm cột "Tiền quy đổi" đó trong CSDL. Cột "Tiền quy đổi" chỉ hiển thị trên báo cáo, màn hình mà thôi.

Lập phiếu điều chỉnh (Credit Note) trong phần mềm, em thường cho nhập trong chính màn hình mua, bán nhưng vào số liệu (số lượng hàng nếu liên quan tới kho) là âm, việc xác định tài khoản giảm trừ doanh thu hay giảm trừ kho hay giá vốn sẽ lấy từ bảng danh mục hàng hóa. Trong danh mục hàng hóa em thường setup các tài khoản cho mỗi hàng hóa luôn (Hàng tồn kho, Giá vốn, Hàng bán bị trả lại,...)

Vẫn theo luật, giá trị âm thì định khoản đảo.

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....

(*) Với mẫu phiếu thu, chi có thể vừa thanh toán bằng ngoại tệ (các loại:USD, UR,...), vừa nội tệ, ngoài các thông tin cơ bản của một chứng từ thì cần có một Grid/Table thể hiện việc hạch toán chi tiết:

|Mã chứng từ|Trạng thái|Diễn giải|Chiết khấu|Nợ còn phải trả|Thanh toán|Loại tiền|Tỷ giá| Tài khoản đối ứng|

Phiếu thu, phiếu chi thì chắc chắn phải có chi tiết rồi, nếu ko thì thanh toán làm sao được cho nhiều hóa đơn.

Nếu chỉ có 1 cột "Thanh toán" trong khi dòng 1 có Mã NT là USD, dòng 2 có Mã NT là EUR thì tính sao đây? Tổng tiền thanh toán theo theo cột nào? (Trường hợp thanh toán bằng 2 loại ngoại tệ trở lên mà)

- table công nợ cần thêm 1 field Finished kiểu Binary để kiểm soát hoá đơn đã thanh toán hết hay chưa.

Cái này ban đầu mọi người sẽ nghĩ làm cách này. Tuy nhiên, việc này lập trình ko cẩn thận nhiều khi hóa đơn được thanh toán hết rồi mà Finished (Kiểu boolean chứ) lại = False hoặc ngược lại

Ví dụ nhé:

1/ 1 hóa đơn có giá trị 100tr, phiếu thanh toán cho hóa đơn đó cũng là 100tr ==> Finished = True nhé

Giờ ta tiếp tục sửa hóa đơn làm cho giá trị của hóa đơn là 120tr. Vậy Finished = ?

2/ 1 hóa đơn có giá trị 100tr, phiếu thanh toán cho hóa đơn đó cũng là 80tr ==> Finished = False nhé

Giờ ta quay lại sửa hóa đơn làm cho giá trị của hóa đơn là 80tr. Vậy Finished = ?

Mọi người sẽ thấy nếu cứ dính đến chuyện sửa/xóa chứng từ thì sẽ còn nghĩ ra hàng trăm vấn đề nữa.

Vì thế, 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.

Mà cũng nên khoá những hoá đơn đã check Finished lại không cho sửa. Muốn sửa phải làm bút toán điều chỉnh riêng và phải có Phiếu đề nghị điều chỉnh (cho sợ đừng làm sai).

Đây là điều mong ước, làm cho dân IT nhàn nhất đấy.

Mọi người có biết là ở nhiều đơn vị, họ bán hàng âm kho ầm ầm, sau mấy ngày họ mới làm phiếu chuyển kho/nhập hàng/phiếu điều chỉnh để cho dương kho (ngày ở phía sau mấy chứng từ xuất kho). Lúc đó mọi người thử tính giá vốn mà xem. Nếu xử lý ko cẩn thận, tràn số (giá trị tồn kho) là chuyện hiển nhiên (thế là KH bảo phần mềm lỗi rồi )

 

[cadafi]

To: Anh hai2hai

File đính kèm là schema cho phần khai báo Multi currency của ACCPAC, và giao diện nhập liệu tỳ giá . Anh tham khảo thử xem. Em đang lục lại phần database của Accpac về mảng Account Payable - Payment và Receivable - Receipt. Chắc thứ hai mới gửi lên được.
---------------------------------------

Ý kiến về việc chỉnh sửa chứng từ:
Em cũng là dân kế toán, tuy nhiên em cũng không đồng tình với vấn đề chỉnh sửa chứng từ đã Posted,/Released, hoặc đã ghi sổ cái (tùy theo khái từng loại chứng từ). Nếu User làm sai, nhập sai thì phải điều chỉnh bằng một chứng từ khác, hoặc làm cũng với nghiệp vụ ấy nhưng ngược lại (bút toán đảo).

Nói vậy, nhưng cũng có mấy lần (nghĩa là nhiều lần) em phải chọc thẳng vào SQL và làm động tác (Update....set ...., Delete * from....). Nói vậy là anh biết rồi. Có những lúc chứng từ làm sai, nhưng mình không muốn thấy nó hiện hữu trên cõi đời (database) này. Ví dụ, nhân viên em hạch toán một nghiệp vụ với số tiền 300 triệu VND, vậy mà lại hạch toán 300 triệu USD mới chết chứ! Thế là tự nhiên lên Balance sheet nhìn .... không chịu được.

Cái mà em thấy hay nhất của phần mềm (hình như là Solomon thì phải). Nó cho phép cấp Admin có quyền chuyển trạng thái của chứng từ (nôm na gọi là bật cờ xanh). Ví dụ chuyển từ POSTED sang OPEN, RELEASED sang OPEN, PAID sang OUTSTANDING,etc. Cái hay ở chỗ, khi chuyển như vậy thì tất cả các động thái liên quan và record liên quan đều sẽ undo lại hết, coi như bút toán này chỉ vừa mới được tạo ra và lưu thôi chứ chưa POSTED; dĩ nhiên bút toản này sẽ được chuyển sang một trạng thái khác (ví dụ RE-OPEN chẳng hạn.). Sau đó khi chỉnh sửa xong, ta post lại chứng từ, các động tác như cập nhật chứng từ, tính số dư, lưu phát sinh gì gì đó thì cũng giống như một bút toán/nghiệp vụ bình thường và được gọi ra chạy khi ta ấn nút Lưu/Post/Release.

 

[hai2hai]

To: Anh hai2hai

File đính kèm là schema cho phần khai báo Multi currency của ACCPAC, và giao diện nhập liệu tỳ giá . Anh tham khảo thử xem. Em đang lục lại phần database của Accpac về mảng Account Payable - Payment và Receivable - Receipt. Chắc thứ hai mới gửi lên được.

Đang định cài lại ACCPAC lên máy (hic, đây là PM thứ 5 trong mấy ngày gần đây đã phải cài lên 1 máy tính), có lẽ thôi ko cài nữa nếu có sự giúp đỡ của ca_dafi.