Bạn biết gì về Oracle ERP (Những khó khăn khi cài Oracle)

20/10/2009 Số lần xem: 4455 Chào chú, Thú thật với chú là cháu cũng đã có triển khai Oracle rồi. (Cháu sinh năm 1980 thôi nên gọi chú là chú) Dự án 1 là: Vietsovpetro Dự án 2 là: Bibica (chỉ hổ trợ) Dự án 3 là: Savimex (chỉ hổ trợ) Có một thời từng làm Solomon 1. Nói chung, qua 3 dự án thì cháu cảm thấy là quá mệt mỏi. Những gì cháu viết trong các bài vừa rồi đều là các vấn đề gặp phải khi triển khai. Không chỗ này thì là chỗ khác. Cháu xuất thân là dân Coding, cho nên có nhiều cái phải viết lại lắm. Chẳng hạn đơn giản nhất là cái Uỷ nhiệm chi / Hoặc là TT hoặc là LC. Những cái này khách hàng yêu cầu phải làm. Thế là phải viết mới màn hình uỷ nhiệm chi, màn hình TT, màn hình LC. Đâu chỉ có thế, sau khi có uỷ nhiệm chi, TT, LC rồi thì sẽ có giấy báo nợ của ngân hàng, thế là phải chỉnh tiếp màn hình Receipt của AR và Payment của AP để có thể chọn đựơc uỷ nhiệm chi hoặc TT, hoặc LC đã tạo trước đó. Đây chỉ là vấn đề thứ nhất thôi. Và cháu nghĩ cái này thì chắc chắn chỗ nào cũng đòi làm cho mà xem.

2. Các báo cáo của Oracle rất là tệ hoặc có thể nói là không cái nào dùng được ngoại trừ mấy cái báo cáo phần MFG mà thôi (cái này chỉ cần lấy PL/SQL của Oracle rồi chỉnh lại thành của mình là dùng OK). Còn lại các báo cáo khác như nhật ký chứng từ, bảng kê chứng từ, cân đối phát sinh, cân đối kế toán, lưu chuyển tiền tệ đều không thể dùng của Oracle có nghĩa là phải làm sao đây ta?

3. Phần đánh giá lại chênh lệch tỷ giá của tiền thì cũng mệt nữa, nếu không muốn nói là làm bằng tay.

4. Các User của Việt Nam mình cứ muốn làm sai là sửa, trong khi đó hệ Oracle muốn sửa thì phải làm hơi phức tạp. Nó sẽ lưu lại History và đều có định khoản cho các lần chỉnh sửa.

5. Tài sản cố định thì làm gì có chỗ để nhập tài khoản chứ. Với lại làm gì có các báo cáo kiểu như tổng hợp tình hình tăng giảm và hao mòn TSCD?

6. Các tài khoản lưỡng tính 331, 141, 131 thì tạm thời có thể tính dựa theo các Invoice và Receipt hay Payment để tính số dư lưỡng tính. Các tài khoản kiểu như lương 334, 138 thì làm sao mà có thể có được NKCTừ lưỡng tính?

7. Điều tệ nhất là việc định khoản kép của Việt Nam mình, nếu một nghiệp vụ nào đó làm trong Oracle mà sinh nhiều nợ nhiều có thì làm sao mà viết Code để cho nó lấy đối ứng được chứ? Cái này thì ông giám đốc Oracle Châu Á Thái Bình Dương cũng biết là khó khăn ở Việt Nam.

8. Còn nhiều điều bất cập nữa lắm chú ơi. Nói chung, cháu thấy rằng, thằng Oracle muốn phát triển thị trường ở Việt Nam thì nó phải viết một bộ cho Việt Nam mới xong.

9.T hằng SAP (Có Metro Cash dùng thì phải) cháu nghe nói là nó làm tốt phần PO và AP khác tỷ giá map với nhau. Còn Oracle thì làm hơi cực mà theo cháu thấy cũng hơi bị chuối.

10. Chuyển giao diện sang tiếng Việt cũng là điều mệt mỏi đó chứ.

11. Phần sản xuất thì cũng còn nhiều thứ phải bàn cãi nhiều, qui trình của Oracle rất phức tạp, nếu làm sai một cái là nó tính ra giá thành sai be bét luôn.

12. Báo cáo thuế đầu ra và đầu vào nếu dùng Oracle thì tuỳ từng nơi sẽ có cách làm khác nhau. Nói chung là cực vô cùng. Ví dụ đối với nghiệp vụ chi tiền điện nước chẳng hạn: Nợ 133, Nợ 627 / Có 111 => Dùng Misc của Receipt của AR để nhập cái này cũng phải in ra báo cáo thuế đầu vào.

13. Các phân hệ chi tiết định khoản làm âm được. Ví dụ đơn giản là: Nợ 331 / Có 112 (ngân hàng gửi giấy báo nợ về rồi, nhưng sau đó bên nhận thông báo là tài khoản bị Close nên chuyển tiền tại, khách hàng không chịu ghi Có 331 / Nợ 112 mà muốn ghi âm Nợ 331 / Có 112). Cái này có thể dùng GL để nhập nhưng định khoản liên quan đến tiền mà làm ở GL thì làm sao mà in báo cáo thu chi quĩ được chứ?

14. Còn nhiều lắm, tạm thời cháu nói bấy nhiều đó thôi.

Lấy ví dụ dùng Oracle đi nhé:

Phần AR

1. Công ty con bán hàng Nợ 131/ Có 511 = 100USD

2. Công ty mẹ thu tiền của khách hàng (thu hộ, không phát hoá đơn), ngân hàng trừ phí ngân hàng: Nợ 112 / Có 136(công ty con) = 90 USD (phí ngân hàng = 9 USD + 1 USD là thuế)

3. Công ty mẹ báo cho công ty con: Nợ 642 = 9, Nợ 133 = 1, Nợ 136(công ty mẹ) = 90/ Có 131 = 100 USD
=> Đối với AR chỉ có cách dùng hoặc là:

3.1 Credit Memo: Nợ 131 = 1, Nợ 136 = 90, Nợ 642 = 9/ Có 131 = 100 (làm tại công ty con)

3.2 Áp cái Invoice với cái Credit Memo để cấn trừ công nợ. (cách này sẽ có chênh lệch tỷ giá nhiều nợ nhiều có =>không dùng được)
hoặc dùng 2 Receipts: 1 Cash và 1 Misc trong AR nhưng lúc đó sẽ có khác biệt

3.1B: Nợ 136 = 100 / Có 131 = 100 (Cash)

3.2B: Nợ 131 = 1, Nợ 642 = 9/ Có 136 = 10

Cách này sai bản chất của vấn đề => Sếp kế toán của doanh nghiệp có cho làm hay không?

Phần PO và AP:

PO làm tỷ giá = 15000, khi phát hoá đơn cho AP tỷ giá là 15500 => Match PO và AP rất phức tạp

Phần AP và AR sẽ có chênh lệch tỷ giá đối với trường hợp WRITE OFF

(Invoice và Receipt của AR cùng tỷ giá nhưng vẫn có chênh lệch tỷ giá; phần Invoice và Payment cùng tỷ giá nhưng vẫn có chênh lệch tỷ giá)

Dùng Mass Allocations của GL để phân bổ chi phí thì OK nhưng để kết chuyển chi phí, doanh thu thì phức tạp.

Phần FA thì củ chuối vì làm gì có các định khoản giống AR, AP, GL, ... khi nhập liệu => làm sao đây?

MFG => Luôn tính theo ngay hệ thống. Lúc test sau Set up phải chỉnh ngày hệ thống => cục gạch luôn.

Căng nhất là các báo cáo thuế đầu vào đầu ra (phần thuế đầu vào của nhân viên đi công tác -> vé máy bay, vé tàu, vé cầu đường có thuế đầu vào ....) làm được thì cực vô cùng, chắc là phải làm chuối rồi.

Làm gì có các báo cáo như : Bảng cân đối kế toán, lưu chuyển tiền tệ, tình hình nộp ngân sách nhà nước, .....

Các phân hệ chi tiết (AR, AP, ...) không nhập định khoản âm được. Làm cáh nào đây?

Một vài khó khăn cùng chia sẻ với quí cô chú và các anh chị
(Nguồn: webketoan)