2.2.1. Sơ đồ và miêu tả.
Sơ đồ 2.1: chu trình báo cáo kế toán:
Qua sơ đồ 2.1, thực trạng qui trình báo cáo kế toán xảy ra thông qua các bước sau:
Doanh thu của công ty được ghi nhận dựa vào thông tin của các đơn bán hàng cho khách hàng trong kỳ. Hàng ngày, các bộ phận hoạt động ghi nhận các thông tin hoạt động bán hàng (khách hàng, dịch vụ, ngày tàu đến, ngày tàu chạy, sản lượng...) vào hệ thống hoạt động MORE/MODS/TURNEL.... Những đơn bán hàng hoàn thành sẽ được bộ phận hoạt động ghi nhận trong SAP R/3 vào tài khoản (TK) phải thu khách hàng/TK trích trước doanh thu. Chủ nhật hàng tuần, trung tâm dịch vụ toàn cầu (GSC) sẽ thực hiện việc chạy chương trình ghi nhận doanh thu cho Mlog ở tất cả các nước trên toàn cầu. Khi chương trình này hoàn tất, doanh thu của những đơn hàng này sẽ chuyển vào SAP R/3 để ghi nhận vào TK doanh thu/TK trích trước doanh thu. Số liệu trên TK trích trước doanh thu sẽ được tự động cấn trừ nếu thông tin chi tiết từng đơn bán
hàng khi ghi nhận riêng lẽ (Doanh thu được ghi nhận trước phải thu, phải thu được ghi nhận trước doanh thu) là khớp nhau. Chi tiết việc tạo các đơn bán hàng sẽ được làm rõ trong chu trình doanh thu-phải thu khách hàng.
Chi phí của công ty được ghi nhận dưới hai dạng là biến phí và định phí:
- Biến phí được tập hợp căn cứ vào các đơn mua hàng mà công ty đã thực hiện với nhà cung cấp trong kỳ. Các đơn mua hàng này được liên kết với các đơn bán hàng tương ứng để phục vụ cho việc báo cáo số dư đảm phí mà bộ phận hoạt động tạo ra được trong kỳ một cách trung thực nhất.
- Định phí được tập hợp từ các chi phí cố định của các bộ phận hoạt động như lương, các khoản liên quan đến lương, chi phí khấu hao máy móc thiết bị nhà xưởng, chi phí bán hàng....Chúng được ghi nhận vào các trung tâm chi phí trực tiếp cho từng bộ phận hoạt động.
- Ngoài ra, định phí còn được phân bổ từ các trung tâm chi phí gián tiếp (những trung tâm chi phí chức năng này tập hợp chi phí của các bộ phận gián tiếp như phòng hành chánh, nhân sự, kế toán và máy tính) thông qua chu kỳ đánh giá vào cuối tháng. Chi tiết việc tạo các đơn mua hàng sẽ được làm rõ trong phần chu trình chi phí-phải trả nhà cung cấp.
Hàng tuần, bộ phận báo cáo trích xuất thông tin doanh thu-chi phí ghi nhận được trong tuần gửi cho bộ phận hoạt động để kiểm tra và theo dõi xem những đơn mua-bán hàng trong tuần đã được ghi nhận doanh thu chi phí đầy đủ hay chưa. Từ đó, có kế hoạch sửa chữa, bổ xung chi tiết các đơn mua-bán hàng cho đúng để chi phí và doanh thu được ghi nhận kịp thời trong sổ kế toán của tập đoàn.
Hàng tháng, bộ phận báo cáo một mặt trích xuất tất cả các doanh thu, chi phí hoạt động trong kỳ gửi các bộ phận hoạt động để kiểm tra và chắc rằng doanh thu, chi phí trong kỳ đã được ghi nhận đầy đủ. Mặt khác, bộ phận báo cáo còn phải thực hiện các bút toán trích trước cần thiết để ghi nhận doanh thu, chi phí hoạt động cho những đơn mua-bán hàng đã thực hiện nhưng chưa kịp ghi nhận kịp thời.
Thêm vào đó, bộ phận báo cáo cũng phải rà soát, so sánh và đánh giá lại tất cả những định phí trong kỳ với ngân sách đã vạch ra để xem có thiếu sót định phí nào chưa được ghi nhận hay không. Thực hiện các bút toán phân bổ, trích trước cần thiết để đảm bảo định phí được phản ánh đúng nhất hoạt động và các giao dịch trong kỳ.
Bên cạnh đó, bộ phận báo cáo cũng phải kiểm tra các chu kỳ đánh giá, chương trình phân bổ...để đảm bảo định phí ghi nhận một cách đầy đủ và hợp lý.
Cuối cùng, bộ phận báo cáo phải chuyển thể kết quả kinh doanh trên hệ thống SAP vào hệ thống quản trị tài chính cao cấp HFM của Tập đoàn cho mục đích quản trị và ra quyết định cấp Tập đoàn.
2.2.2. Đánh giá ưu nhược, nguyên nhân, ảnh hưởng. 2.2.2.1. Ưu điểm: 2.2.2.1. Ưu điểm:
Toàn bộ các khía cạnh chi phí đã được xem xét, so sánh với ngân sách được lập từng tháng. Điều này giúp cho công ty không bỏ sót các chi phí đã thấy trước được và thực hiện việc trích trước chi phí đó hàng tháng để chi phí trong kỳ không bị biến động quá cao giữa các kỳ.
Toàn bộ các khía cạnh doanh thu đã được xem xét, đánh giá và điều chỉnh chi tiết hàng tuần. Điều này giúp cho công ty hạn chế khả năng bị bỏ xót, ghi nhận trùng doanh thu hoạt động cho những đơn mua đã thực hiện trong kỳ. Có hệ thống các trung tâm chi phí để ghi nhận chi phí trực tiếp của từng bộ phận. Là công cụ hữu ích giúp cho nhưng người quản lý trực tiếp kiểm soát và chịu trách nhiệm về chi phí của bộ phận đó.
Có chu kỳ đánh giá cuối tháng để phân bổ chi phí gián tiếp của các bộ phận gián tiếp vào chi phí trực tiếp của các bộ phận hoạt động. Điều này giúp nhà quản trị kiểm soát được biến động chi phí trên cấp độ công ty ở từng quốc gia cũng như toàn tập đoàn.
2.2.2.2. Nhược điểm:
Việc theo dõi các khoản trích trước doanh thu và chi phí được thực hiện bằng tay. Do đó, khả năng trích trước thừa, thiếu là hoàn toàn có thể xảy ra. Điều này làm cho báo cáo có thể phản ánh không đúng (nhiều hơn, hoặc ích hơn so với số liệu thực tế mà nó đáng lẽ phải được thể hiện. Nếu nhiều quá, hoặc ít quá có thể ảnh hưởng trọng yếu đến doanh thu, chi phí có liên quan. Doanh thu được ghi nhận trên cơ sở hàng tuần. Điều này gây khó khăn trong việc theo dõi những điều chỉnh cho các doanh thu ghi thiếu, ghi thừa. Ví dụ như có một trăm nghiệp vụ ghi sai và được phát hiện vào thứ hai, đã được điều chỉnh trong thứ hai đó nhưng đến thứ hai tuần sau mới biết được kết quả điều chỉnh đó có được phản ánh hay chưa. Trung bình có khoản hai mươi ngàn nghiệp vụ cần ghi nhận doanh thu trong một tuần cho hoạt động của Maersk Logistics ở Việt Nam.
2.2.2.3. Nguyên nhân và ảnh hưởng:
Do các khoản trích trước được thực hiện vào cuối mỗi tháng trong khung thời gian rất ngắn với khối lượng lớn các nghiệp vụ đã được ghi nhận trong SAP nên việc trích thiếu, trích thừa chi phí, doanh thu là thường xuyên xảy ra. Điều này gây biến động không đúng của doanh thu chi phí giữa các kỳ. Việc tìm hiểu nguyên nhân và giải thích biến động là thực hiện được nhưng tốn kém nhiều thời gian và chi phí.
Người ghi nhận các đơn mua hàng có thể nhầm lẫn trong việc chọn các trung tâm chi phí, tài khoản dẫn đến báo cáo tài chính thể hiện không đúng bản chất tài khoản và bộ phận, đơn vị gánh chịu chi phí. Với khối lượng nghiệp vụ lớn trong tháng (khoản một trăm năm chục ngàn nghiệp vụ), kế toán báo cáo không đủ thời gian để xem xét, liên lạc với các bên liên quan để điều chỉnh cho đúng hết những nghiệp vụ sai sót.
2.3. Thực trạng chu trình doanh thu- phải thu: 2.3.1. Sơ đồ và mô tả. 2.3.1. Sơ đồ và mô tả.
Chu trình doanh thu được thiết kế cho hai mảng hoạt động khác nhau. Một là chu trình tự động được áp dụng cho hai bộ phận IEL và OCE và hai là chu trình bằng tay được áp dụng cho ba bộ phận AIR, LSS và WND.
Sơ đồ 2.2: giao dịch giữa Mlog và khách hàng:
Qua sơ đồ 2.2, khái quát giao dịch như sau:
Mlog giao dịch với người bán (Shipper) và người mua (Consignee) như một công ty duy nhất nhưng nếu xét về nội bộ thì các mối giao dịch thực chất sẽ là Mlog Orgin (Mlog-Ori) (nơi xuất khNu) sẽ thực hiện giao dịch với Shipper và Mlog Destination (Mlog-Des) (nơi nhập khNu). Trong khi đó, Mlog-Des sẽ thực hiện giao dịch với Mlog-Ori và người mua (Consignee).
Chu trình nào sẽ xảy ra tự động và cho bộ phận nào? Chu trình nào được thực hiện bằng tay? Sơ đồ 2.3: các chu trình tự động và không tự động.
Gọi chu trình tự động là vì IEL và OCE sử dụng hệ thống MODS để cập nhật thông tin bán hàng ở Mlog-Ori mà theo đó thông tin sẽ được tự động chuyển sang hệ thống của Mlog-Des. Cũng theo đó và các trường như MSO,
DSO…trong SAP cũng được tự động cập như khi hệ thống được đáp ứng các điều kiện nhất định.
Các khái niệm về MODS, SAP, MSO, DSO…sẽ được làm rõ ở các trình bày sau.
2.3.1.1. Chu trình tự động:
Chu trình doanh thu tựđộng này chỉ áp dụng cho bộ phận IEL và OCE.
Sơ đồ 2.4: chu trình doanh thu tự động tổng thể cho Mlog-Ori và Mlog-Des sẽ như sau:
Một cách khái quát: Khách hàng liên hệ Mlog yêu cầu cung cấp dịch vụ, sau khi thỏa thuận Mlog sẽ lập hợp đồng, đồng thời tạo Hợp đồng/báo giá cho một lô hàng (shipment) sẽ được tạo SAP R/3. Thông tin của lô hàng đó trên hợp đồng/báo giá kết hợp với thông tin hoạt động của nó (hàng gì, đi tàu nào, ngày tàu chạy, ngày tàu đến, ai là người liên lạc…) được cập nhật trên MODS sẽ tạo ra đơn bán hàng (MSO)/Đơn bán hàng đã được quyết toán số lượng (DSO) trên SAP R/3. Những DSO đến hạn sẽ là căn cứ để tạo ra hóa đơn trong SAP (Billing Document-BD). Những BD đến hạn thu tiền sẽ là căn cứ để nhắc nhở khách hàng, nhận thanh toán và quyết toán công nợ với khách hàng.
Ví dụ một dòng dữ liệu được tạo ra trong SAP:
Hợp đồng/báo giá số 40046750, mục 20 có MSO số 10590796, mục 20 có DSO số 10681430, mục 20 có doanh thu được ghi nhận số 6000171205 có BD số
5148393948 có bút toán phải thu khách hàng số 5148393948, chưa được quyết toán với khác hàng (not cleared).
Sơđồ 2.5: Sơđồ chu trình doanh thu Maersk Logistics ở nước xuất khu:
Qua sơ đồ 2.5 ở trên, các bước của chu trình như sau:
Qui trình được bắt đầu từ sự kiện khách hàng liên hệ công ty yêu cầu cung cấp dịch vụ. Đó có thể là yêu cầu xuất một lô hàng từ Việt Nam đi Úc, từ Mỹ sang Việt Nam…Phòng kinh doanh của Mlog-Ori và khách hàng sẽ làm việc với nhau để thống nhất giá cả, số lượng hàng hóa, container, hạn mức tín dụng, thời hạn thanh toán, ngày giao hàng, cảng bốc, cảng dỡ, người liên lạc, hình thức nhận hàng,… Giá cả và loại dịch vụ sẽ được cam kết với nhau thông qua hợp đồng với khách hàng. Căn cứ vào thông tin trên hợp đồng được ký kết, bộ phận hoạt động sẽ tạo hợp đồng/báo giá tương ứng trên SAP. Hợp đồng/báo giá này phải được người có thNm quyền duyệt, đây là căn cứ xác định giá cho dịch vụ mà Mlog đã cung cấp cho khách hàng.
SAP R/3 là hệ thống phần mềm kế toán, hoạt động được thiết kế để hạch toán tình hình hoạt động kinh doanh thường nhật cho Mlog.
Sơ đồ 2.6: Chu trình tạo hợp đồng/báo giá:
Qua sở đồ 2.6 ở trên, chu trình tạo hợp đồng/báo giá được thực hiện qua các bước sau:
Khách hàng liên hệ với các bộ phận của Mlog (IEL, OCE, AIR, LSS, WND) yêu cầu cung cấp dịch vụ vận chuyển, hậu cần, kho bãi…Mlog đánh giá tính hấp dẫn của khách hàng (sản lượng có nhiều hay không? Mức lợi nhuận trên một đơn hàng có hấp dẫn không? Khả năng thanh toán của khách hàng có tốt không?...) rồi thương thảo với khách hàng về giá, điều kiện giao nhận…và tiến hành lập hợp đồng sau khi có sự thống nhất từ hai phía. Phòng hoạt động sẽ tạo hợp đồng/báo giá trên SAP và thực hiện những thay đổi, sữa chữa cho đến khi hoàn chỉnh để được duyệt. Mlog căn cứ vào hợp đồng với khách hàng để tiến hành cung cấp dịch vụ.
Hình sau đây là ví dụ một hợp đồng/báo giá đã được tạo trong SAP R/3:
Căn cứ vào thông tin mà khách hàng đặt hàng, phòng kinh doanh sẽ thông báo cho bộ phận hoạt động để cập nhật dữ liệu của dịch vụ như số đơn đặt hàng, số lượng, tên người bán, tên người mua…vào hệ thống có tên là MODS. Lý do mà
Mlog sử dụng hệ thống MODS này là vì khách hàng (NIKE, ADIDAS, TARGET…) có thể đăng nhập vào hệ thống và theo dõi được chi tiết tình hình cụ thể của hàng (hàng đã đi đến nước nào, cảng nào, người liên lạc…). Đồng thời MODS còn giúp Mlog giảm bớt khối lượng công việc trùng lắp giữa Mlog-Ori và Mlog-Des. Những dữ liệu hoạt động được nhập liệu trên MODS ở Mlog-Ori sẽ tự động chạy sang hệ thống SAP của Mlog Des với những điều kiện nhất định.
MODS là hệ thống được dùng để cập nhật các thông tin hoạt động của Mlog như: khách hàng nào đặt hàng? Đơn hàng số mấy? Dịch vụ gì? Số lượng bao nhiêu? Khi nào thì khởi hành, kết thúc…Sau khi các thông tin về hoạt động được cập nhật đầy đủ trong MODS thì người cập nhật MODS sẽ lưu tình trạng của đơn hàng trên MODS (Shipping Order-S/O) là “Đã sẵn sàng chuyển qua SAP (Ready For Fact-RFF=Y)”.
Dưới đây là hình minh họa cho 1 S/O được tạo và cập nhật trong MODS:
Sau khi tình trạng của S/O là “Đã sẵn sàng chuyển qua SAP”, thông tin hoạt động của S/O này sẽ được tự động chuyển qua SAP. SAP tự động tìm và liên kết thông tin của S/O này với hợp đồng/báo giá đã được lập ở bước trên để tạo ra một MSO. Như vậy thông tin trên MSO bao gồm thông tin về hoạt động có được từ thông tin của S/O được cập nhật trên MODS kết hợp với thông tin về giá, loại dịch vụ, khách hàng…có được từ hợp đồng/báo giá trong SAP. Từ
MSO, SAP sẽ tự tạo ra một yêu cầu mua hàng (Purchasing Requisition-PR). Như vậy MSO là căn cứ để phân bổ chi phí mua hàng.
Có hai loại MSO là ZO02-Origin MSO-Hàng xuất khNu và ZO04-Destination MSO-Hàng nhập khNu. Ở Mog-Ori thì các MSO được tạo ra đều có dạng là ZO02. Tương tự vậy các MSO ở Mlog-Des sẽ có dạng là ZO04. Phân biệt loại MSO là để giúp cho người kiểm soát hệ thống có thể trích trước doanh thu và chi phí ở một con số gần chính xác nhất. Vì theo thiết lập của SAP thì doanh thu và chi phí được ghi nhận căn cứ vào ngày tàu chạy cho Mlog-Ori, ngày tàu đến cho Mlog-Des. Các điều kiện ghi nhận doanh thu và chi phí sẽ được trình bày chi tiết ở phần sau.
Ví dụ một MSO được tạo trong SAP từ S/O ở MODS:
Sau khi có MSO, SAP R/3 lập tức tự động tạo ra một yêu cầu mua hàng. Vì hoạt động của Mlog chủ yếu là mua đi bán lại dịch vụ nên Mlog nhận cung cấp dịch vụ cho khác hàng thì lập tức đặt dịch vụ này ở một hãng tàu. Việc đặt lại dịch vụ này có thể là thời điểm khách hàng liên hệ với Mlog để đặt dịch vụ hoặc vào đầu năm tùy vào đó là bộ phận gì. Thường thì AIR LSS và WND sẽ đặt dịch vụ nhà cung cấp cho cả một chu kỳ dài hạn. Có thể là một, hai hay năm năm tùy thỏa thuận. Đặt dịch vụ dài hạn như vậy sẽ giúp Mlog ổn định được nguồn cung, giá rẽ, hoạch định được chiến lược giá dễ dàng. Thường giá
bán mong muốn của Mlog đối với khách hàng là bằng hoặc cao hơn giá đã đặt dài hạn với nhà cung cấp cộng lợi nhuận mong muốn.
Sau khi Mlog biết rõ số lượng cụ thể của lô hàng cần vận chuyển cho khách hàng thì biên bản nhận hàng (Frieght Cargo Receipt-FCR/House Bill of Lading-HBL) trên MODS sẽ được cập nhật là “đã nhận hàng”. Điều này có nghĩa là Mlog đã xác nhận với khách hàng về số lượng hàng mà mình đã nhận vận chuyển. Sau đó DSO được tự động tạo trên SAP. Thông tin trên DSO có