Chi Tiet Chuyen Doi So Lieu & Khoa So Cuoi Ky

HDCV: Chuyển đổi dữ liệu Lần ban hành/Sửa đổi 1/0

I.Tổng quan

I.1 Mục tiêu tài liệu

Tài liệu này nhằm mục đích hướng dẫn cho các cán bộ dự án tư vấn triển khai tại FES.HCM thực hiện các công việc chuẩn bị chuyển đổi, thực hiện chuyển đổi số liệu một cách chi tiết.

I.2 Nội dung tài liệu

Nội dung tài liệu là các hướng dẫn chi tiết bổ sung cho các mô tả quá trình Chuyển đổi dữ liệu trong Sổ tay quá trình tư vấn triển khai, liên quan đến các vấn đề chính sau đây:

Chuyển đổi số đầu kỳ Đối chiếu và đóng sổ cuối kỳ

Hiện tại tài liệu chỉ đề cập đến 4 phân hệ chính là: tài chính, mua hàng, vật tư và bán hàng, chưa đề cập đến phân hệ sản xuất. Các qui trình nêu trong tài liệu là các qui trình chuẩn, không tính những phần customize theo yêu cầu của khách hàng. Để sử dụng tốt tài liệu này, yêu cầu các cán bộ TVTK:

Nắm vững được các phân hệ chi tiết liên quan Đã lập xong chiến lược và kế hoạch chuyển đổi số liệu

II. Nội dung

1. Chuyển số đầu kỳ

Danh sách các khoản cần chuyển đổi vào hệ thống bao gồm những phần sau:

STT Phân hệ

Tên Loại Cách chuyển

Ghi chú

1. GL Các segment của hệ thống tài khoản

Danh mục Dataload

2. GL Accounting Period Danh mục Dataload

3. GL Currency Danh mục Manual Do đã có sẳn trong hệ thống nên chỉ cần active để sử


dụng

4. GL Số dư chi tiết các tài khoản

Số liệu ADI

5. GL Combination Danh mục Dataload Combine các segment của HTTK

6. AP Payment Term Danh mục Dataload

7. AP Input VAT Danh mụcDataload

8. AP Bank Account Danh mụcDataload

9. AP Supplier Type Danh mụcDataload

Phân loại supplier

10. AP Supplier Danh mục Interface

11. AP Employee Danh mụcDataload

12. AP Distribution Set Danh mụcDataload

Những định khoản lặp đi lặp lại nhiều lần của AP

13. AP Chi tiết công nợ nhà cung cấp

Số liệu Interface Chú ý theo số PO

14. AP Chi tiết công nợ tạm ứng

Số liệu Interface

15. AR Payment Term Danh mụcDataload

16. AR Output VAT Danh mụcDataload

17. AR Customer Category Danh mụcDataload

Phân loại Customer

18. AR Customer Class Danh mụcDataload

Tập hợp các customer có cùng tính chất: Payment term, Credit limit...

19. AR Customer Danh mục Interface Chú ý Relationship

20. AR Transaction Type Danh mụcManual

21. AR Transaction Source Danh mụcManual

22. AR Receipt Class Danh mụcManual

23. AR Receipt Source Danh mụcManual

24. AR Chi tiết công nợ khách hàng


25. FA Category Danh mục Dataload


26. FA TSCĐ Danh mục ADI

27. INV Category Danh mục Dataload

28. INV UOM Danh mục Dataload Đơn vị tính

29. INV Account AliasDanh mục

Dataload

30. INV Danh mục vật tưDanh mục

Interface

31. INV Số dư chi tiết tồn kho Số liệu

32. OM Sales personDanh mục

Dataload Chú ý phần Hierachy

33. OM Bảng giáDanh mục

Interface

34. OM Chương trình khuyến mãi

Danh mụcInterface

35. OM Order TypeDanh mục

Dataload

36. OM Số dư các hợp đồng, đơn hàng nếu có


37. PO Buyer Danh mục Dataload

38. PO Số dư các hợp đồng nếu có

Số liệu Dataload

Các bước thực hiện việc chuyển đổi số liệu :a. Chuẩn bị template lấy số liệu

Cán bộ triển khai phải chuẩn bị đầy đủ các template nêu trên trước khi đưa cho khách hàng. Template tốt nhất là bằng excel và được giải thích cụ thể, chi tiết các cột để khách hàng có thể hiểu được. Cán bộ triển khai chỉ nên dùng 1 trong 3 cách chuyển đổi: Dataload, Interface và ADI tránh trường hợp nhập manual rất dễ sai sót. Do danh sách cần chuyển rất nhiều nên cán bộ TVTK nên phân bổ thời gian lấy hợp lý để khách hàng có điều kiện để chuẩn bị. Template lấy số cần có thứ tự, format theo đúng chuẩn của file dataload, Interface hoặc ADI tuỳ theo phương pháp chuyển đổi. Nếu có những cột không cần thiết thì ẩn đi, tránh làm cho khách hàng hiểu nhầm.

b. Yêu cầu về số liệu

- Xác định rõ mốc thời gian nhận được số liệu từ khách hàng, phạm vi các phân hệ cần chuyển đổi, khối lượng số liệu cần chuyển đổi. Phải đảm bảo khách hàng chốt số liệu tại thời điểm đã thống nhất trong chiến lược chuyển đổi.- Số liệu nhận từ khách hàng phải có bằng chứng xác nhận và phải đảm bảo đây là số liệu đã được đóng sổ trên hệ thống cũ.


- Số liệu yêu cầu khách hàng cung cấp phải phù hợp với giải pháp đề xuất đặc biệt là loại “Số liệu”, nên chú ý các trường hợp sử dụng “Flexfiled” . Ngoài ra, cán bộ TVTK phải xem xét lại mức độ ảnh hưởng của các báo cáo, có thể khách hàng cung cấp thiếu thông tin để phục vụ cho các báo cáo liên quan.

Yêu cầu chi tiết:

STT Phân hệ

Tên Yêu cầu


Cung cấp chi tiết giá trị của từng segment. Lưu ý có một số tài khoản là Asset nhưng theo giải pháp phải set-up là Liability (“Tạm ứng”,...)

2. GL Accounting Period Xác định thời điểm cần chuyển đổi để tạo kỳ kế toán. Danh mục này không cần khách hàng cung cấp. Cơ sở để tạo là chiến lược chuyển đổi số liệu đã được khách hàng thông qua

3. GL Currency Chỉ rõ loại tiền và số lẻ của từng loại được sử dụng trong hệ thống

4. GL Combination Cung cấp đầy đủ mối liên kết giữa các segment


Phải có số dư chi tiết của từng tài khoản đã được thống nhất theo giải pháp và theo danh mục tài khoản đã được combine. Rất nhiều trường hợp khách hàng chỉ chuyển số liệu tổng hợp, cán bộ TVTK cần phải chú ý vấn đề này khi yêu cầu cung cấp. Nên gởi bảng hệ thống tài khoản mới để khách hàng tham khảo và chuẩn bị.

Ngoài ra để tiện cho việc đối chiếu, cán bộ TVTK nên xin bảng cân đối tài khoản để kiểm tra xem đã đầy đủ hay chưa.

Số dư phải chuẩn bị theo từng loại tiền để đảm bảo tính chính xác của số đầu kỳ.

6. AP Payment Term Lưu ý các khoản discount nếu có(Trả sớm sẽ được chiết khấu...)

7. AP Input VAT Lưu ý tài khoản thuế tương ứng

8. AP Bank Account Lưu ý tài khoản tiền và loại tiền

9. AP Supplier Type Tiêu chí phân loại khách hàng

10. AP Supplier -Tài khoản AP và tài khoản Pre-payment phải được thực hiện đúng như giải pháp đề xuất.


Thông thường hai tài khoản này phải khác nhau trừ những trường đặc biệt khác.

-Nếu có thống kê theo “Supplier Type” thì phải khớp với danh mục “Supplier Type” đã cung cấp

-Nếu khách hàng có nhiều chi nhánh(Operating Unit) cùng sử dụng một nhà cung cấp thì phải liệt kê chi tiết sử dụng ở chi nhánh nào.

-Nếu nhà cung cấp đó có nhiều nơi thì cũng phải yêu cầu liệt kê chi tiết(Vd: FDC -> Hà Nội và Tp.HCM)

11. AP Employee - Nếu có sử dụng phân hệ HR thì số liệu cần chuẩn bị sẽ nhiều và rất phức tạp

- Nếu chỉ dùng để tạm ứng thì số liệu đơn giản hơn

- Mỗi doanh nghiệp thường có mã số nhân viên riêng vì vậy khi đổ vào hệ thống mã nhân viên nên lấy theo mã này.

12. AP Distribution Set Có những nghiệp vụ phải trả xãy ra thường xuyên và lập đi lập lại nhiều lần, để tiện cho người sử dụng không cần phải định khoản lại yêu cầu họ gởi danh mục này. Lưu ý các tài khoản phải được combine trước đó.


-Oracle sẽ quản lý chi tiết công nợ theo hoá đơn, hợp đồng và nhà cung cấp. Tuỳ theo giải pháp đề xuất mà số liệu đầu kỳ cần cung cấp chi tiết đến mức nào. Nếu muốn quản lý theo tuổi nợ thì phải có điều kiện thanh toán và ngày hoá đơn.

-Nếu nhà cung cấp là nước ngoài cần có thông tin chi tiết về loại tiền, nguyên tệ và ngoại tệ hoặc tỷ giá. Thông thường cán bộ TVTK nhập ngoại tệ và tỷ giá, hệ thống sẽ tự tính nguyên tệ, vì vậy để tránh sai xót nên tính trước tỷ giá bằng excel để đảm bảo nguyên tệ và ngoại tệ luôn chính xác.

-Nếu khách hàng đã có hệ thống thì nên yêu cầu mã nhà cung cấp

- Phải phân biệt một cách rõ ràng giữa công nợ phải trả và trả trước (Lưu ý theo giải pháp chuẩn thì 2 tài khoản công nợ này khác nhau)


-Nếu doanh nghiệp không thể cung cấp số liệu chi tiết theo từng hoá đơn phải có biên bản thống nhất cách xử lý đặc biệt là báo cáo tổng hợp công nợ.

-Số liệu chi tiết công nợ cần được đối chiếu với bảng cân đối kế toán. Vì theo cách lấy chuẩn của Oracle sẽ lấy theo số dư từng hoá đơn nên có thể lệch với doanh nghiệp(lấy theo từng nhà cung cấp)


-Oracle sẽ quản lý chi tiết công nợ theo từng lần tạm ứng của nhân viên. Tuỳ theo giải pháp đề xuất mà số liệu đầu kỳ cần cung cấp chi tiết đến mức nào. Nếu muốn quản lý theo tuổi nợ thì phải có điều kiện thanh toán và ngày tạm ứng.

-Nếu doanh nghiệp đã có hệ thống thì nên yêu cầu mã nhân viên

- Phải phân biệt một cách rõ ràng giữa công nợ tạm ứng và phần còn thiếu nhân viên

- Số liệu chi tiết tài khoản tạm ứng phải khớp với bảng Cân đối kế toán trên tổng hợp

15. AR Payment Term Lưu ý các khoản discount nếu có(Trả sớm sẽ được chiết khấu...)

16. AR Output VAT Lưu ý tài khoản thuế tương ứng (Có cho sửa tiền thuế hay không)

17. AR Customer Category Tiêu chí phân loại khách hàng

18. AR Customer Class Thiết lập các khách hàng có chung một số tính chất: điều kiện thanh toán, tính phí,...

19. AR Customer -Nếu có thống kê theo “Customer Category” thì phải khớp với danh mục “Customer Category” đã cung cấp. Tương tự như Customer Class

-Nếu doanh nghiệp có nhiều chi nhánh(Operating Unit) cùng sử dụng một khách hàng thì phải liệt kê chi tiết sử dụng ở chi nhánh nào.

-Nếu khách hàng đó có nhiều địa chỉ thì cũng phải yêu cầu liệt kê chi tiết(Vd: FDC -> Hà Nội và Tp.HCM)


20. AR Transaction Type Yêu cầu khách hàng liệt kê tất cả các giao dịch công nợ phải thu bao gồm:

-Thu trước

-Bán hàng nhập khẩu

-Bán hàng nội bộ...

-Doanh thu nhận trước

Chú ý các tài khoản tương ứng: Doanh thu, thuế, phải thu(Công nợ hay thu trước) phải thực hiện theo giải pháp

21. AR Transaction Source

22. AR Receipt Class

23. AR Receipt Source Liệt kê tất cả các giao dịch phải thu, lưu ý tài khoản phải được combine trước


-Oracle sẽ quản lý chi tiết công nợ theo hoá đơn, hợp đồng và khách hàng. Tuỳ theo giải pháp đề xuất mà số liệu đầu kỳ cần cung cấp chi tiết đến mức nào. Nếu muốn quản lý theo tuổi nợ thì phải có điều kiện thanh toán và ngày hoá đơn.

- Nếu khách hàng là nước ngoài cần có thông tin chi tiết về loại tiền, nguyên tệ và ngoại tệ hoặc tỷ giá. Thông thường cán bộ TVTK nhập ngoại tệ và tỷ giá, hệ thống sẽ tự tính nguyên tệ. Vì vậy để tránh sai xót nên tính trước tỷ giá bằng excel để đảm bảo nguyên tệ và ngoại tệ luôn chính xác.

-Nếu doanh nghiệp đã có hệ thống thì nên yêu cầu mã khách hàng

- Phải phân biệt một cách rõ ràng giữa công nợ phải trả và trả trước (Lưu ý theo giải pháp chuẩn thì 2 tài khoản công nợ này khác nhau)

- Nếu doanh nghiệp muốn quản lý công nợ theo salesman thì yêu cầu cung cấp chi tiết.

-Nếu doanh nghiệp không thể cung cấp số liệu chi tiết, phải có biên bản thống nhất cách xử lý

-Số liệu chi tiết công nợ cần được đối chiếu với bảng cân đối kế toán. Vì theo cách lấy chuẩn của Oracle sẽ lấy theo số dư từng hoá đơn nên có thể


lệch với cách lấy của doanh nghiệp (Lấy theo từng khách hàng)

25. FA Category Cách phân nhóm TSCĐ

26. FA TSCĐ Do đặc thù của TSCĐ nên khi yêu cầu cung cấp số liệu phải rất rõ ràng. Ví dụ nếu muốn lấy số liệu đầu kỳ tháng 8 thì phải lấy số của tháng 6 và nhập mới trong tháng 7, sau đó chạy khấu hao và đóng kỳ.

Số liệu chi tiết tài khoản tài sản, khấu hao phải khớp với bảng Cân đối kế toán trên tổng hợp

27. INV Category Cách phân nhóm vật tư trong hệ thống ERP. Có bao nhiêu cách phân loại:

- Kinh doanh

- Vật tư

- Kế toán...

28. INV UOM Danh sách các đơn vị tính. Nếu doanh nghiệp sử dụng nhiều ĐVT thì phải yêu cầu phần chuyển đổi giữa các đơn vị tính. Cần chú ý chữ hoa, chữ thường, tên viết tắt hay tên thay thế của ĐVT. Phải yêu cầu doanh nghiệp thống nhất trước khi chuyển vào hệ thống

29. INV Account Alias Liệt kê chi tiết tất cả các giao dịch nhập-xuất của doanh nghiệp. Chú ý phần tài khoản đối ứng đồng thời các nghiệp vụ này nên bám vào giải pháp để đảm bảo không xót các giao dịch nhập xuất.

30. INV Danh mục vật tư Danh sách các vật tư, thành phẩm trong hệ thống. Cần chú ý theo giải pháp là vật tư, thành phẩm tương ứng được sử dụng ở Org nào, đơn vị tính chính là gì?

31. INV Số dư chi tiết tồn kho Phải cung cấp đầy đủ: số lượng, đơn giá, thành tiền, đơn vị tính, kho, org. Phải đảm bảo ĐVT đã tồn tại trước đó. Thông thường doanh nghiệp sẽ cung cấp số lượng tồn và thành tiền vì vậy nếu giải pháp chuyển số đầu kỳ dùng nhập Misc thì phải xử lý số lẻ trước khi đưa vào hệ thống. Phải đảm bảo số lượng*đơn giá= thành tiền(Số mà doanh nghiệp cung cấp – Nên dùng excel để tính)


Số liệu chi tiết tài khoản vật tư, hàng hoá phải khớp với bảng Cân đối kế toán trên tổng hợp

32. OM Sales person Cần chú ý là các salesman có phân theo cấp hay không?

33. OM Bảng giá Bảng giá của của các sản phẩm có theo khách hàng, nhóm khách hàng, ngày hiệu lực và vị trí địa lý hay không? Hoặc theo số lượng?

Cần phân biệt trường hợp vừa có bảng giá cho khách hàng, vừa có “Contract agreement” với khách hàng đó


Các chương trình khuyến mãi và thời gian áp dụng cũng như đối tượng áp dụng

35. OM Order Type


Trong một số trường hợp vẫn có những hợp đồng, SO mà doanh nghiệp chưa giao hết. Tuỳ theo giải pháp cán bộ TVTK phải thống nhất với doanh nghiệp các điểm sau:

1. Chỉ chuyển số dư hay là chuyển toàn bộ số lượng của hợp đồng. Trong trường hợp phải chuyển toàn bộ, thì phải chú ý đến tồn kho và công nợ vì phải thực hiện thao tác ship đi lượng hàng đã xuất trong quá khứ

2. Bảng giá và chương trình khuyến mãi có tác động đến hợp đồng này không?

37. PO Buyer Cần chú ý cấp duyệt, job và position


Trong một số trường hợp vẫn có những hợp đồng mà doanh nghiệp chưa nhận hết. Tuỳ theo giải pháp cán bộ TVTK phải thống nhất với doanh nghiệp chỉ chuyển số dư hay là chuyển toàn bộ số lượng của hợp đồng. Trong trường hợp phải chuyển toàn bộ, thì phải chú ý đến tồn kho và công nợ phải trả vì phải thực hiện thao tác receipt(bỏ để khớp số dư) lượng hàng đã xuất trong quá khứ

c. Kiểm tra số liệu trước khi chuyển đổi

1. Đảm bảo chỉ có 1 kỳ duy nhất được mở trong lúc hệ thống chuyển đổi


2. Đảm bảo ngày hệ thống phải là ngày nằm trong kỳ chuyển đổi. Ví dụ nếu muốn chuyển đổi số đầu kỳ kỳ 8, thì ngày hệ thống ít nhất phải là 23/07 để tạo khoảng cách an toàn. Nếu thời gian chuyển đổi quá dài thì nên kéo dài ngày hệ thống. Việc đổi ngày sẽ phức tạp nếu thực sự hệ thống đã có những giao dịch xãy ra trước đó (Giao dịch đã có kỳ 9) nên cán bộ TVTK phải chú ý trường hợp này

3. Các số liệu do doanh nghiệp cung cấp phải được xác nhận: người cung cấp, ngày cung cấp, thời điểm cung cấp

4. Tất cả các số liệu, danh mục phải được kiểm tra tính đầy đủ trước khi import vào hệ thống. Ví dụ:

- Số dư chi tiết công nợ phải có nhà cung cấp khớp với danh mục nhà cung cấp, điều kiện thanh toán khớp với danh mục “Payment term”, tài khoản công nợ phải khớp với danh mục tài khoản…

- Phải in check-list các “danh mục”, “số liệu” cần kiểm tra để tiện cho việc theo dõi

d. Hướng dẫn chuyển đổi số liệu

1. Thứ tự chuyển đổi

a. Cán bộ TVTK cần phải chuyển đổi loại “danh mục” trước, loại “số liệu” sau

b. Ưu tiên chuyển đổi các loại “danh mục” độc lập trước, loại phụ thuộc sau. Vd: Phải chuyển đổi “Supplier Type” trước khi chuyển đổi “Supplier”

2. Đối với loại “Số liệu” hoặc “Danh mục phụ thuộc” cần phải chuẩn bị các “từ điển” liên quan phát sinh trong hệ thống để sử dụng. Ví dụ: Khi nhập số dư công nợ phải trả, cần phải biết mã nhà cung cấp trong hệ thống phát sinh là số bao nhiêu

3. Nên back-up hệ thống trước khi chuyển đổi. Mục nào phức tạp cần phải thực hiện test trước khi chuyển đổi. Sau khi chuyển đổi xong hệ thống danh mục phải back-up lại

4. Tài khoản đối ứng trong quá trình chuyển đổi là tài khoản suspense. Thông thường tài khoản này là “00000000”

5. Thứ tự và cách chuyển đổi thực hiện theo các bước sau:


STT Phân hệ

Tên Cách chuyển

Các mục cần có trước khi

chuyển

Cách thực hiện Cách đối chiếu


DataloadNone

Export ra excel để đối chiếu hoặc chạy báo cáo “Chart of Accounts - Segment Values Listing”

2. GL Accounting Period DataloadNone

3. GL Currency ManualNone


ADIFinal

-Nên thực hiện sau khi các phân hệ chi tiết đã hoàn tất

-Xoá hoặc reverse(change sign)tất cả các chứng từ được post qua từ phân hệ chi tiết: AR, AP, FA, INV, PO, MFG

-Dùng ADI để chuyển đổi theo nhiều loại tiền khác nhau. Nên set-up thuộc tính cho sửa tiền VND trong khi chuyển đổi nhằm tránh sai xót đối với loại ngoại tệ. “Batch name” nên đặt tên gợi nhớ: DAUKY_VND, DAUKY_USD, ngày nên lấy ngày đầu kỳ hoặc ngày cuối kỳ để dễ nhớ

-Post tất cả số liệu phát sinh

- In báo cáo “Trial Balance – Detail” để đối chiếu

- In báo cáo”Bảng tổng kết tài sản” để đối chiếu với khách hàng.

-Số liệu nếu đúng, yêu cầu khách hàng ký nhận


-Kiểm tra số dư trong hệ thống nếu có sai xót thì tiến hành điều chỉnh bằng cách nhập chứng từ âm

5. GL Combination Dataload1

Export ra excel để đối chiếu

6. AP Payment Term DataloadNone

In báo cáo “Payment Terms Listing” để đối chiếu (Có thể dùng Discoverer)

7. AP Input VATManual 1,5

In báo cáo “Tax Names Listing” để đối chiếu

(Có thể dùng Discoverer)

8. AP Bank AccountDataload 1,5

In báo cáo “Bank Account Listing” để đối chiếu


9. AP Supplier TypeDataload None

In báo cáo “Payables Lookup Listing” để đối chiếu với loại là “Vendor Type”


10. AP Supplier Interface1,5,9

In báo cáo “Supplier Report” để đối chiếu



11. AP EmployeeDataload 1,5,9

In báo cáo “Supplier Report” để đối chiếu


12. AP Distribution SetDataload 1,5


Interface1,5,9,10

-Chỉ thực hiện khi danh mục nhà cung cấp đã hoàn chỉnh

-Đổ bằng Interface

-Kiểm tra số dư trong hệ thống nếu có sai sót thì tiến hành điều chỉnh bằng cách nhập chứng từ âm

-Sau khi hoàn chỉnh phải post tất cả chứng từ qua GL

-Bên GL sẽ reverse các chứng từ này bằng cách change sign

Dùng Discoverer hoặc báo cáo chi tiết, tổng hợp công nợ.

Lưu ý tính đối chiếu giữa bảng tổng hợp công nợ và báo cáo tổng kết tài sản. Đảm số số phải trả, số trả trước của hai báo cáo này giống nhau


Interface1,5,9,11

-Chỉ thực hiện khi danh mục nhân viên đã hoàn chỉnh


-Kiểm tra số dư trong hệ thống nếu có sai sót thì tiến hành điều chỉnh bằng cách nhập chứng từ âm


-Bên GL sẽ reverse các chứng từ này

Dùng Discoverer


bằng cách change sign

-Đóng kỳ khi số liệu đã hoàn chỉnh (Công nợ nhà cung cấp, tạm ứng)

15. AR Payment TermDataload None

In báo cáo “Payment Terms Listing” để đối chiếu (Có thể dùng Discoverer)

16. AR Output VATDataload 1,5

In báo cáo “Tax Names Listing” để đối chiếu


17. AR Customer CategoryDataload None

Có thể dùng Discoverer

18. AR Customer ClassDataload None


19. AR Customer Interface17,18

Sử dụng “Customer listing summary or detail” để đối chiếu (Có thể dùng Discoverer)

20. AR Transaction TypeManual 1,5

Sử dụng “Transaction Types Listing” để đối chiếu

21. AR Transaction SourceManual

Sử dụng “Transaction Batch Source Listing” để đối chiếu

22. AR Receipt ClassDataload 1,5



23. AR Receipt SourceManual



Interface1,5,17,18,19

-Chỉ thực hiện khi danh mục nhà cung cấp, transaction type, source,.. đã hoàn chỉnh


-Kiểm tra số dư trong hệ thống, nếu có sai sót thì tiến hành điều chỉnh bằng cách nhập chứng từ âm



25. FA Category Dataload1,5

Dùng “Asset Category Listing” để đối chiếu

26. FA TSCĐ ADI1,5,25

Dùng “Asset Description Listing” để đối chiếu

27. INV Category DataloadNone

Item categories report

28. INV UOM DataloadNone


29. INV Account Alias Dataload1,5


30. INV Transaction Type Dataload27,28


31. INV Số dư chi tiết tồn kho1,5,27,28,30

-Chỉ thực hiện khi danh mục nhà cung cấp, transaction type, source,.. đã hoàn chỉnh



-Kiểm tra số dư trong hệ thống, nếu có sai sót thì tiến hành điều chỉnh bằng cách lập chứng từ nhập hoặc xuất



-Đóng kỳ khi số liệu đã hoàn chỉnh

32. OM Sales person Dataload Có thể dùng Discoverer

33. OM Bảng giá Interface1,5,27,28,30,17,18,19 Có thể dùng Discoverer


Interface1,5,27,28,30,17,18,19 Có thể dùng Discoverer

35. OM Order Type Dataload Có thể dùng Discoverer


Interface1,5,27,28,30,17,18,19,33,34 Có thể dùng Discoverer

37. PO Buyer Dataload1,5,9,11

Sử dụng “Buyer listing” để đối chiếu


Dataload1,5,9,10,27,28,30 Sử dụng “Purchase Order

Detail Report” để đối chiếu


3. Đối chiếu số liệu cuối kỳ

Đối chiếu số liệu cuối kỳ là công việc hết sức quan trọng và cần thiết khi vận hành hệ thống ERP nhằm đảm bảo số liệu giữa các phòng ban là đầy đủ và tính xác. Sau đây là cách đối chiếu và thứ tự đối chiếu

STT Phân hệ Cách đối chiếu1. OM

(1 Operating Unit nên set up 1 sequence)

1. Đối chiếu giữa doanh thu bán hàng trong phân hệ kế toán phải thu và SO ở phân hệ OM 1.1 In báo cáo liệt kê tất cả các SO với trạng thái, số tiền tương ứng ở phân hệ OM, số hoá đơn nếu có trong kỳ cần đối chiếu để tính tổng số tiền đã ra hoá đơn 1.2 In báo cáo doanh thu trong kỳ ứng với số SO tương ứng 1.3 So sánh báo cáo 1.1 và 1.2, nếu lệch nhau về giá trị cách kiểm tra như sau:- Cả hai báo cáo đều có SO nhưng giá trị lệch nhau: dùng chứng từ gốc để kiểm tra (hoá đơn đỏ). Có thể hoá đơn có giảm giá, chiết khấu mà phòng kinh doanh không biết- SO ở 1.1 có (Shipped) nhưng 1.2 không có: Phòng kế toán nhập thiếu hoá đơn hoặc phòng kinh doanh nhập sai quên điều chỉnh hoặc kế toán đã xoá HĐ đi. Nên kiểm tra ở Interface của AR để biết chính xác- Doanh thu ở 1.2 có nhưng 1.1 không có: Phòng kế toán nhập tay hoặc xoá đi trường SO - Doanh thu và giá vốn không đồng bộ (khác ngày): Căn cứ trên chứng từ gốc để chỉnh sửa2. Đối chiếu giữa OM và INV- Xem xét có những giao dịch nào bị pending không xuất hàng được hay không?- Nếu có giao dịch còn pending phải tìm hướng giải quyết- Đối chiếu kho tạm với số lượng tương ứng theo SO. Nếu kho tạm có hàng thì transfer về kho chính- Số ship phải được kho xác nhận (Xuất bán)

2. PO Nếu triển khai Periodic Cost phần PO đối chiếu không nhiều. Nếu bộ phận PO có theo dõi và lập đề nghị thanh toán sẽ có đối chiếu với phải trả thông qua Phiếu nhập, PO và hoá đơn thanh toán

3. INV(Phân quyền response Inventory, WIP, không cho chọn 152?)

1. Đối chiếu của Kho với thủ kho đúng về mặt lượng (Nhập, xuất, tồn hoặc thẻ kho). Lưu ý các giao dịch Intransit2. Đối chiếu với OM, PO nếu có3. Xem xét có giao dịch nào bị pending hay không? Nếu có phải tìm ra nguyên nhân và xử lý4. Chạy draft Periodic Cost4.1 Đối chiếu 331009 bên có với AP (Tham khảo chi tiết file đối chiếu 331009 )


4.2 Đối chiếu sổ chi tiết, sổ tổng hợp với báo cáo nhập xuất tồn kho về giá trị. Nếu lệch thông thường rơi vào các trường hợp sau: - Tài khoản kho và tài khoản đối ứng giống nhau - Dùng Update cost có Variance, tài khoản là tài khoản kho - Số lẻ5. Đối chiếu các tài khoản trung gian dùng để chuyển kho nội bộ: 151/152009/155009. Đảm bảo số dư các tài khoản này bằng 0. Nếu có giá trị thì phải tìm hiểu do hạch toán sai tài khoản đối ứng hay do có một qui trình nào đó thực hiện chưa hoàn tất (Căn cứ theo tài liệu giải pháp– Chuyển kho giữa các org,…)6. Phải set-up riêng tài khoản Variance. Cuối kỳ nên in các tài khoản này ra, nếu có phát sinh đề nghị kế toán tổng hợp xử lý (Chuyển vào chi phí,…)7. Đóng kỳ averagve cost (Toàn bộ các Org)8. Đóng kỳ Periodic Cost9. Chuyển chứng từ qua tổng hợp

4. Tiền Việc đối chiếu thu chi tiền được thực hiện định kỳ hàng ngày, hàng tuần chứ không nhất thiết đối chiếu chỉ 1 lần vào cuối tháng Tiền mặt/ Ngân hàng- Đối chiếu với tiền tồn tại quỹ/ sổ phụ ngân hàng- Nếu lệch thì phải tìm hiểu nguyên nhân. Lệch bên thu thì kiểm tra lại báo cáo phải thu: có thể do hạch toán tài khoản đối ứng sai, có một số tiền chưa apply,..Nếu lệch bên chi cũng có thể do nguyên nhân tương tự hoặc bút toán đó chưa định khoản- Kiểm tra các tài khoản trung gian liên quan đến tiền(113: 111->112/112->112/Ban Viet mua USD): Đảm bảo các tài khoản trung gian này=0, nếu khác 0 thì có 1 chứng từ/ 1 qui trình chưa thực hiện

5. AP 1. Đối chiếu 331009 bên nợ với INV (Tham khảo chi tiết file đối chiếu 331009 )2. Đối chiếu tài khoản Clearing Asset (211009/241009) với tài sản cố định. Nếu lệch thông thường do các nguyên nhân sau: - Kế toán định khoản nhầm tài khoản - Quên chuyển chứng từ cho kế toán TSCĐ (Nên dùng “Payables Account Analysis Report”)Qui trình đối chiếu chi phí gia công/ hoặc các tài khoản trung gian khác cũng tương tự3. Xem xét có giao dịch nào còn chưa định khoản hay không- In báo cáo “Unaccounted Transactions Report”- Định khoản tất cả các giao dịch này4. In báo cáo sổ chi tiết tài khoản đối chiếu với bảng tổng hợp công nợ (Bao gồm các tài khoản công nợ: 331,141,338,…). Nếu lệch thì do các nguyên nhân sau:- Kế toán hạch toán tài khoản đối ứng chính là tài khoản công nợ- Core Fin (Nếu còn duy trì) có thể sai. Đối chiếu bằng cách dùng báo cáo “Payables Account Analysis Report” để so sánh với CoreFin.


- In báo cáo lỗi Core Fin và xử lý nếu có6. Đối chiếu phần chi của kế toán tiền mặt, tiền gởi ngân hàng (Tham khảo chi tiết qui trình đối chiếu tiền)7. Chuyển số liệu qua tổng hợp8. Đóng kỳ AP. Lưu ý, kỳ AP đóng cho Legal Entity nên chỉ có một đơn vị có quyền đóng kỳ này

6. AR 1. Đối chiếu với phân hệ OM phần doanh thu, giá vốn để đảm bảo tính đồng bộ (Tham khảo chi tiết phần OM)2. Xem xét có giao dịch nào còn chưa định khoản hay không- In báo cáo “Incomplete Invoices Report”- Định khoản tất cả các giao dịch này3. Xem xét có khoản tiền nào chưa apply hay không- In báo cáo “Unapplied Receipts Register”- Nếu có Receipt nào chưa apply thì tìm hiểu nguyên nhân và hiệu chỉnh4. In báo cáo sổ chi tiết tài khoản đối chiếu với bảng tổng hợp công nợ (Bao gồm các tài khoản công nợ: 131,138,…). Nếu lệch thì do các nguyên nhân sau:- Kế toán hạch toán tài khoản đối ứng chính là tài khoản công nợ- Core Fin (Nếu còn duy trì) có thể sai. Đối chiếu bằng cách dùng báo cáo “Sale report” để so sánh với CoreFin5. Đối chiếu phần thu của kế toán tiền mặt, tiền gởi ngân hàng (Tham khảo chi tiết qui trình )6. Chuyển số liệu qua tổng hợp7. Đóng kỳ AR. Lưu ý, kỳ AR đóng cho Legal Entity nên chỉ có một đơn vị có quyền đóng kỳ này

7. FA 1. Đối chiếu với AP tài khoản clearing2. Xem xét khấu hao, thanh lý3. Đóng kỳ

8. GL 1. Import tất cả các bút toán từ phân hệ chi tiết vào tổng hợp. Lưu ý phân hệ INV thường phải sử dụng Interface nên phải kiểm tra phần này đã được import chưa( Periodic Cost cho phép Import trực tiếp vào GL mà không cần)2. Sau khi import xong nên kiểm tra xem có phần nào báo lỗi hay không. Nếu có có thể dùng chức năng Correct của GL để hiệu chỉnh3. In bảng cân đối trước và sau khi post của Core Fin (Nếu có sử dụng)4. Nếu lệch nhau: các trường hợp lỗi (Nhiều nợ, nhiều có) chưa xử lý hết)/ Tong PS cua CoreFin<>Oracle (131)5. Nếu tài khoản suspense có số dư hay số phát sinh phải xem xét lại các giao dịch6. Có trường hợp tài khoản được sử dụng một thời gian sau đó chuyển thành tài khoản cha hoặc disable đi, sẽ làm lệch đi bảng cân đối. Nên in báo cáo riêng các tài khoản này, đảm bảo số dư của chúng phải bằng 0 trước khi disable hoặc chuyển thành tài khoản cha


7. Post tất cả các chứng từ8. In bảng cân đối lại một lần nữa để xác định là các chứng từ đã được Post9. Thực hiện các chức năng: kết chuyển, phân bổ của phân hệ GL. Sau đó Post các chứng từ10. Kiểm tra các tài khoản chi phí, doanh thu đã triệt tiêu (=0). Nếu chưa phải thực hiện điều chỉnh hoặc phân bổ lại11. In bảng tổng kết kế toán. Đối chiếu các mục với phân hệ chi tiết, đặc biệt là kho, tiền, công nợ. Nếu lệch thì phải tìm nguyên nhân và hiệu chỉnh12. Đóng kỳ nếu các số liệu trên đã chính xác


II.3 Phụ lục cách chuyên đôi tiêng Việt băng Dataload

Hiện tại công cụ dataload không hỗ trợ cho việc đổi tiếng việt. Để khắc phục tình trạng này cán bộ TVTK nên tiến hành các bước sau:

1. Set up Language : Regional and Language options -> Language, check “Install files for...”

2. Ơ tab Advanced chọn Vietnamses

3. Dữ liệu dùng Vietkey convert sang “Vietnamses locale CP 1258”

4. Chạy dataload và kiểm tra font Unicode

Người duyệt Người xem xét Người lập

Trần Công Sơn

Documents

Chi Tiet Chuyen Doi So Lieu & Khoa So Cuoi Ky