Nhật ký triển khai SAP cho trang trại Bò sữa-Triển khai ERP hiệu quả ở Việt Nam

Bạn dao_accountant@yahoo.com chia se kinh nghiệm theo tiến trình triển khai SAP ECC 6.0 cho trang trại bò sữa.

Phòng TCKT hiện tại gồm 12 CBNV đảm trách cả 2 mảng FI và CO. nhưng Organize chart của phòng là 21 người mới đủ đáp ứng được yêu cầu công việc. chúng tôi đã rất khó khăn để lựa chọn ra 4 người fulltime + 01 người part time trong SAP.

Tôi là General Accountant và may mắn được trở thành một thành viên core team để tham gia full time với SAP.

Dự án SAP sẽ được phân làm 3 giai đoạn: Blue print, training, testing, kế hoạch hoàn thành trong vòng 4 tháng để golive vào cuối năm 2011.

……………………….

Hôm nay là ngày đầu tiên chúng tôi bắt đầu triển khai xây dựng Blueprint của SAP. Tuy là buổi đầu tiên của dự án nhưng đã có những tranh luận rất hào hứng về việc tính giá thành bò, giá thành sữa, thiết lập BOM cho bò và các bảng tính standard cost of cow, đặc biệt tranh luận về việc gán cho giá trị variance của bò vào AUC bò hay là milking cow. Rồi đến việc phân bổ các chi phí lãi vay, vốn hóa lãi vay vừa cho bò cho sữa, bò tăng trưởng, các AUC xây dựng, nông nghiệp, đền bù GPMB.

Tranh luận về COGS, COGM, P&L và các cách thức SAP sẽ làm dựa trên standard cost, planning cost, actual cost.

……………………….

Hôm nay chúng tôi thảo luận về CC & PC structure hierarchy. Đây là một phần mấu chốt nhất để quyết định theo dõi trung tâm chi phí và các trung tâm lợi nhuận sau này để quản lý giám sát chi phí các trung tâm và để xác nhận các trung tâm lợi nhuận cho cả hệ thống kế toán tài chính và cả kế toán quản trị sau này.

Để lập được cấu trúc CC hợp lý nhất, cần phải xem xét yếu tố trọng yếu của CC đó cần quản trị những trung tâm nào, trong kế toán quản trị càng mở nhiều CC nghĩa là quản lý chi phí càng chi tiết và dễ dàng đối chiếu, kiểm soát chi phí actual và planning, nhưng trong kế toán tài chính lại lien quan đến việc hạch toán các tài khoản. mọi bút toán hạch toán chi phí đều phải đi kèm với CC. nếu mở ra quá nhiều CC sẽ rất khó khăn cho việc hạch toán sau này, vì mỗi bộ chứng từ hạch toán lại có thể lien quan đến cùng lúc nhiều CC; ngoài ra còn khó khăn cho sự phân bổ các chi phí HO, overheads.

Để đi đến thống nhất được chúng tôi phải làm việc trực tiếp với lãnh đạo các phòng ban, các trung tâm trồng trọt, các trại,…. Cùng với sự nghiên cứu lại toàn bộ dự án, cả mô hình định hướng quản lý, tổ chức, organize chart, location, cluster farm, plant, Field crop….

Bước tiếp theo để xác nhận PC chúng tôi đã phải tranh luận rất nhiều về việc xác định các trung tâm lợi nhuận, phải xác định được sản phẩm nào là trọng yếu để tính giá thành, tính giá thành phân đoạn hay giá thành toàn bộ.

Vì mô hình công ty quá rộng, đa dạng và có nhiều phân đoạn khác nhau, nhiều lĩnh vực khác nhau nên phải xem xét giá thành phân đoạn và tính lãi lỗ cho nhiều bộ phận khác nhau, là các cụm trại, các trại, các nhà máy sản xuất, các trung tâm và các vùng nguyên liệu, đồng cỏ.

Người lãnh đạo thì càng muốn phân mảnh càng tốt, để làm cơ sở đánh giá kết quả các manager, director của các PC. Nhưng người thực hiện sau này cho các công tác theo dõi, hạch toán lại là các kế toán. Nếu thiết lập quá nhiều PC, có thể sẽ rất khó cho việc hạch toán và phân bổ chi phí sau này, mọi việc lại phải làm nhiều bằng các bản phân bổ, bảng tính các hệ số bằng Excel để hạch toán vào SAP.

Cuối cùng tôi đã có được một bản draft về cấu trúc CC & PC, rồi đến việc quan trọng nữa là xây dựng cho cấu trúc CC, PC một hierarchy hợp lý nhất, khoa học nhất bằng các mã code để configure hệ thống. Tôi đã có được một bản draft structure Hierarchy gồm 130 CC và 14 PC cho việc tiếp tục thảo luận với CFO và đội tư vấn CSC ngày sau.

……………………….

Hôm qua là một ngày quá bận rộn với dự án SAP mà mình không thể có một chút thời gian nhàn rỗi nào để viết lại đôi chút về SAP cả. buổi chiều về tới nhà xong mình mở máy tính làm ngay các bảng biểu mà CSC cung cấp template, dự dịnh viết xong sớm để viết tóm tắt vào nhật ký này nhưng mà cũng chẳng có thời gian. Sáng nay như thường lệ, đúng 5h chuông điện thoại báo thức, mình lại dậy hoàn thiện nốt phần còn lại của các báo cáo để sang thảo luận với đội tư vấn CSC.

Hôm nay đã thảo luận 05 vấn đề quan trọng là:

COA công ty 1000;

Bản mapping activity type từ các chi phí tại các trại, nông nghiệp, nhà máy để thực hiện kết chuyển auto sau này.

SAP có thể thực hiện được 02 phương pháp phân bổ chi phí là:

–          Phân bổ theo distribution: Phân bổ chi tiết từng chi phí 622, 627 cho các cost center. Ưu điểm PP này là ở các cost center được phân bổ có thể biết được chi tiết từng loại chi phí, nhưng nhược điểm là ở cost center được phân bổ không thể phân biệt được chi phí nào được phân bổ và chi phí nào là chi phí gốc của cost center đó, vì nó cộng dồn vào các hạng mục chi phí tương ứng, mặt khác các chi phí gốc sẽ bị triệt tiêu khi phân bổ cho các cost center khác.

–          Phân bổ theo Assessment: nghĩa là group các chi phí tương đồng trong các  TK 622, 627 vào một số nhóm nhất định lấy TK 9942…. Làm nhóm để rồi phân bổ. nhược điểm cách này là phức tạp và phải mở các TK mới khác với COA thường, nghĩa là nó xuất hiện các tài khoản group ngoài hệ thống tài khoản VAS. Nhưng ưu điểm là các chi phí gốc 622,627 được phân bổ cho các CC, và tại các PC tương ứng có thể biết được chi tiết từng account item. Và chi phí gốc vẫn còn, không bị triệt tiên như phẩn bổ distribution.

Sau khi thảo luận và nhận định rõ thực tế để lựa chọn PP phẩn bổ, chúng tôi đi đến cách phân bổ theo PP assessment. Mở các tài khoản group để có thể theo dõi chi tiết các chi phí labor, depreciation, finance expense… (các chi phí chủ chốt, chiếm tỷ trọng lớn) tại các CC được phân bổ. như vậy khi xem chi phí ở các cost center sẽ xem được các loại chi phí cụ thể được phân bổ như chi phí labor, utility, depreciation, interest expense … và biết được cả nguồn phân bổ từ các CC cụ thể như từ logistic, manternance, quarantine, garage, vet lab….tuy nhiên phải itemize cho mỗi sự phân bổ từ mỗi cost center bằng 1 account mới.

Bản final CC & PC structure;

Bản default các chi phí chênh lệch (CL giá contract & PO, CL đánh giá hàng tồn kho, CL giá do chuyển kho, CL thanh toán, CL tỷ giá TT, thu nhập CL TGTT, thu nhập thanh toán, chiết khấu……);

Về bản COA vẫn chưa kết thúc được trong ngày vì có quá nhiều tài khoản và phải sắp xếp, ấn định các tài khoản clearance, các TK tương ứng hàng tồn kho và chi phí, các chi phí nguyên vật liệu thuộc BOM hay raw material, và xác định các bán thành phẩm…. rồi lại đặt mã ID để configure vào hệ thống, các TK trong tên short list tối đa 20 ký tự…. nói chung để hoạch định một COA chuẩn cho việc quản lý cả trong 2 mảng FI,CO là rất phức tạp, nó như một nền móng của một công trình xây dựng, nếu nó không chuẩn thì có thể cả hệ thống sau này sẽ phải theo dõi, kiểm soát off-SAP nhiều.

Về việc default các chi phí chênh lệch, CP tài chính, thu nhập tài chính, các chi phí nợ xấu và quản lý khác từ các PC vào các mã CC thích hợp cũng tốn rất nhiều thời gian và phải nghiên cứu kỹ mới quyết định được. sau khi default rồi sẽ configure vào hệ thống để auto kết chuyển sau này. Nhưng đã có một số trường hợp xảy ra như: chi phí thuộc PC này lại chung chung, không thể xác nhận lại được cho các CC, vì vậy mở thêm một số CC trong CC&PC structure hierarchy để xác nhận các chi phí đó của PC vào các CC tương ứng bằng cách mở các CC như general admin CC hoặc Dummy CC, nó thuộc các CC mẹ.

Hiện tại đang tạm xây dựng một template của các bước chạy sự phân bổ các giá trị chệnh lệch, các cái khác cần phân bổ.

Tuy nhiên để bảng biểu này hòan thiện cần phải hoàn thiện hệ thống CoA trước..

……………………….

Mr. CFO có ý định mở thêm profit center cho CC garage với mục đích sau này garage phục vụ cho cả công ty TH Sugar. Sau khi discuss xong chúng tôi quyết định ok mở thêm PC garage và tách CC garage thành 01 CC mẹ, tách khỏi logistic center. Tôi phải làm ngay cái new version CC&PC structure hierarchy gửi cho Gilbert và tư vấn CSC trước lúc configuration vào hệ thống, lại phải làm lại bảng fix phân bổ các chênh lệch từ PC đến CC.

……………………….

Hôm nay chúng tôi được giới thiệu qua cái interface của SAP và một số quy trình trong SAP trong các T-Code AP,AR.

Mặc dù để thực hiện một nghiệp vụ kinh tế phát sinh phải qua nhiều bước hơn thường lệ các phần mềm khác nhưng phải công nhận rằng thằng SAP nó quản lý quá chặt chẽ và phân hệ rõ rang cho các phần hành sử dụng.

Mỗi khoản outgoing payment đều phải qua clearing nên dễ dàng nhận biết và kiểm soát được cho các line item đã được downpament từ trước.

Tuy nhiên tất cả các chi phí đều hạch toán qua AP cả thì cũng chưa flexible lắm cho các chi phí trực tiếp từ FI, ví dụ chi thanh toán các chi phí chung chung HO hay OH thường ngày chẳng hạn.

Chúng tôi đã có ý kiến làm trực tiếp trên GL các chi phí đó, nhưng không ổn. mà chỉ có các chi phí đặc biệt, các chi phí lương, phúc lợi mới sử dụng GL để hạch toán.

Trong SAP cũng có thể post chứng từ vào ngày trước today, tuy nhiên số document numer lại tự sinh ra theo thứ tự tăng dần, không thể sửa, không thể nhảy cóc. Nghĩa là số hiệu chứng từ chạy không theo ngày.

Mọi bút toán hạch toán đều qua 2 bước là park document và post document, khi kiểm tra lích sử bút toán sẽ thể hiện cả 2 user này. Tuy nhiên nó không có template để in ra cái phiếu hạch toán.

Mà để tuân thủ theo VAS cùng với việc in ra phiếu hạch toán để enclose với chứng từ gốc để tiện cho việc lưu trữ, tìm chứng từ sau này quyết toán kiểm toán. Tôi đã phải design một cái template của phiếu hạch toán accouting entry gửi cho tư vấn CSC view để có thể configure vào system. Đội tư vấn đã OK và sẽ chuyển ABAP thực hiện công việc customize này.

……………………….

Trao đổi về one time vendor:

Mọi khoản thanh toán invoice đều qua AP.  Nhưng có một số nhà cung cấp nhỏ lẻ, kế toán không muốn mở master data cho vendor đó thì ta thanh toán cho one time vendor, các field information của OTV có thể được hiệu chỉnh tại lúc post nên có thể kê khai information để kê khai thuế.

Tuy nhiên 01 OTV chỉ kê khai thông tin thuế 01 lần, nên chứng từ hạch toán không thể hạch toán cho nhiều hóa đơn.

Giải pháp: lập bảng excel ngoài rồi attachment file vào SAP như một sự ghi chú. Lúc làm kê khai thuế chú ý khoản này để làm thủ công ngoài SAP.

……………………….

Hôm nay tiếp tục làm các bút toán clearing cho vendor.

SAP có cách quản lý rất hay là có thể clearing cho vendor theo từng line item và có thể chọn theo các hình thức clearing partial hoặc residual.

Khi thực hiện các bút toán reverse có các cách reverse như reset only hoặc reset and reverse. Nếu chỉ chọn reset only nghĩa là trả lại document entry như clearing, nhưng nếu chọn reset and reverse thì sẽ arising thêm bút toán reverse, như vậy số total của trial balance sẽ cộng thêm khoản reverse này. Nghĩa là mọi bút toán khi post trong SAP đều được lưu trữ bằng số hiệu document number cụ thể, kể cả các bút toán reverse vẫn được lưu trữ bằng các document number riêng.

Chiều nay là buổi đầu tiên làm việc integration giữa MM và FI gồm có các core team của MM, purchasing và các farm manager.

Có quá nhiều vấn đề lien quan raw material với các chi phí 627 hay 621 trong FI để thống nhất khi default vào hệ thống. vì MM sẽ thực hiện GR/GI theo cái mặc định đó mà không thể hiểu/biết để có các sự lựa chọn cho các chi phí HO,OH, SD như FI.

Và các vấn đề lien quan PR/PO khi bắt buộc đặt CC trong PR hay phải đặt mã asset code trong PO. FI có thể hiểu fixed asset là như thế nào, nhưng liệu MM, Purchasing có thể  xem xét FA đúng theo luật kế toán không để mà fix vào PO.???

Rồi lại lien quan đến các BOM của MM để FI tham chiếu và xây dựng CoA phù hợp nhất. nghĩa là những Raw material đã được xác lập BOM trong MM thì FI không nền mở chi tiết 152,621 cho các RM đó mà vẫn có thể xem xét, quản lý trong phân hệ CO, MM.

Trong công tác xuất kho thành phẩm để sử dụng nội bộ, mặc định cho SAP thực hiện xuất kho hạch toán vào chi phí cost center, phân hệ này do module MM thực hiện. nhưng theo luật thuế VN, chỉ có xuất kho thành phầm tiếp tục quá trình sản xuất kinh doanh mới không phải xuất hóa đơn tài chính. Nhưng nếu đã xuất sữa cho tiêu dung nội bộ hoặc loại thải, biếu, tặng, đổ đi thì cũng phải xuất hóa đơn giá đơn vị bằng giá bán để xác định thuế VAT output phải nộp.

Nhưng nếu MM thực hiện thao tác xuất kho vào chi phí các Cost center thì làm sao module FI kiểm soát được để mà xuất hóa đơn kê khai thuế. Vậy nên để xuất kho tại MD MM hay SD, nếu để SD thực hiện thao tác có nghĩa là như mua bán thường thường, có quá nhiều thao tác trong khi đây không phải là doanh thu có thể đem lại lợi ích kinh tế trong tương lai, nhưng nếu để MM thực hiện thì tính toán thuế VAT OP như thế nào?. Việc này xác nhận rằng bộ phận trực tiếp xuất sữa cho tiêu dung nội bộ phải có đề nghị xuât sữa cụ thể và được approved bởi FI để FI thông qua và xuất hóa đơn tính thuế phải nộp cho nhà nước.

Trong SAP ta coi bò là các MR là một trong các yếu tố tạo BOM của lứa bò lớn hơn. Nghĩa là bò 5 tháng tuổi bằng bò 4 tháng + tiền ăn 1 tháng + nhân công +….. nghĩa là mỗi loại bò là 01 BOM. Tuy nhiên để có số liệu chính xác cho các báo cáo chu chuyển bò tại ngày cuối tháng và lấy số liệu đó GR/GI vào SAP là một công việc đòi hỏi phải chính xác kịp thời. nhưng nó lại lien quan đến các trại, lien quan đến phần mềm AFIFAM để lấy các số chính xác.

Phần mềm AFIFAM là phần mềm hữu dụng nhất hiện nay trên thế giới để quản lý bầy đàn động vật nuôi. Tuy nhiên TH group lại là quy mô quá rộng lớn để áp dụng nó, AFIFAM chưa có phân hệ consolidate giữa các trại với nhau để tạo một báo cáo  chu chuyển đàn toàn bộ hệ thống chuẩn. nên việc summary các báo cáo của các trại lại là phương pháp chiết xuất đối chiếu thủ công.

Mặt khác AFIFAM coi 01 tháng = 30 ngày lại không phù hợp với FI, vì số ngày trong tháng của FI tùy thuộc cụ thể vào tháng đó.

Thứ hai, 01 ngày của AFIFAM cũng coi là 01 tháng nếu nó là ngày đầu của tháng. Nhưng thực tế chu chuyển bò giữa các trại không phải lúc nào cũng trong 01 ngày.

Vấn đề mấu chốt là thống nhất với các trại một cách hiệu quả nhất và có số liệu ngay trong ngày cuối cùng hàng tháng. Nhưng tương lai không chỉ 12 trại mà nó lên đến hàng trăm trại, hàng triệu con bò thì làm sao để quản lý và theo dõi khấu hao, thanh lý bò loại thải….

Rồi lại vấn đề nên đặt 01 asset code cho một lứa bò cho sữa đầu tiên phát sinh trong tháng, hay là thực hiện chương trình upload song song để xem xét 01 con bò là 01 asset code?

Cái này CSC khuyến cáo làm được để tiện cho việc ghi nhận, thanh lý và điều chuyển các bò từ các trại với nhau. Nhưng liệu phần mềm AFIFAM có thể làm được báo cáo chi tiết kèm theo các mã asset code đó để FI có thể đổi chiếu và post vào hệ thống các ngày GR cuối tháng không?…

Vấn đề này đang được tranh cãi và sẽ thảo luận tiếp ngày 26/8/11.

……………………….

Hôm nay bàn luận về các cách thức hiệu quả nhất để thực hiện các nghiệp vụ liên quan đến ngân hàng.

Phải công nhận rằng SAP quản lý dòng tiền quá chặt chẽ, tuy nhiên nó lại làm cho công việc của kế toán mất nhiều thời gian hơn và phải mất một thời gian để làm quen và thực hiện các thao tác nghiệp vụ khác với các cách thực hiện trước đây.

Như việc chuyển tiền từ TK NH này sang tài khoản NH khác chẳng hạn phải qua các bước như FV50 (park doc NH chuyển), FBV0 (post), FCH5(lập UNC), ZFIUNC (in UNC), FCHR (Clearing bank transfer), FB03 (view lại bút toán HT GL), FV50 (Park do NH nhận), FBV0 (post), F-03 (clearing bank transferred).

……………………….

Hợp nhất công việc với module MM. ở dưới các trại sẽ làm PR trên hệ thống, trong hệ thống gốc SAP, làm PR phải ước lượng giá vào để cấp trên duyệt PR, nhưng giá này lại không link tham chiếu các giá đã mua vào PR. Vì vậy người làm PR phải ước lượng giá vào PR. Nhưng thực tế nếu cứ bắt buộc phải ước lượng vào PR thì số đó ở dưới các trại, các đơn vị làm sẽ không chuẩn, vì họ không thể nắm được giá cả sát thực. như vậy cũng đâu có ý nghĩa cho việc quản trị. Vậy chỉ có 02 phương án là hoặc cấu hình cho SAP link giá các đợt mua trước hoặc bỏ giá trị bắt buộc trong PR đi. Nó liên quan đến việc quản trị và thông tin kế toán. Để link giá mua cũ vào PR thì người duyệt sẽ nắm bắt được total giá PR để duyệt PR, nhưng lại để các đơn vị nắm bắt được giá cả, điều này cũng không tốt cho việc quản trị tài chính.

Cuối cùng nhóm core team thống nhất sẽ configure không bắt buộc giá trên PR.

Nói đến PO, lúc mua hàng hóa nếu trong PO có kèm theo giá vận chuyển, lưu cont, thuế nhập khẩu… thì các loại giá này nó mới tính vào tài sản hay giá gốc hàng tồn kho. Tuy nhiên thực tế PO mua hàng nó khác với các PO vận chuyển, lưu công, thuế nhập khẩu…có khi đặt hàng trước, mấy tháng sau hàng về tới cảng hoặc hàng được SX xong mới làm PO vận chuyển và các chi phí liên quan. Nhưng trong hệ thống SAP như thế nó không nhận vào giá gốc hàng tồn kho, vì biết đâu hàng được xuất dung hết mới có PO vận chuyển. vậy chỉ còn cách là ước lượng giá vận chuyển, hải quan, nhập khẩu vào đồng thời PO mua hàng để khi GR ghi nhận các chi phí đó vào hàng tồn kho. Nhưng trong PO lại phải kê khai vonder code luôn, và mỗi khi đã post sẽ không sửa được. thực tế không thực hiện trước việc post vendor code vào, vì ngoài giá cả chưa thống nhất được còn vấn đề chưa chọn nhà vận chuyển nào cả, nên nếu sau này chọn nhà vận chuyển khác thì post PO và GR bị sai về vendor với hóa đơn. Kê khai thuế lại không được như thế này. Vậy làm cách nào đây??? Nếu chi phí vận chuyển, thuế nhập khẩu, tiền hải quan,…. Không ghi nhận vào tài sản, hàng tồn kho sẽ không ghi nhận đúng giá trị hàng tồn kho.

Bên CSC đang thử cấu hình và test thử xem PO có thể thay đổi được information của vendor code không, giá trị thay đổi chắc chắn sẽ không làm được trên SAP, nhưng chỉ thay đổi thông tin vendor thì chưa biết SAP có thể làm được không. Nếu SAP làm được vấn đề này thì mọi việc PR/PO là ok.

Vấn đề invoice receipt vendor nên để MM thực hiện hay FI thực hiện, nếu MM thực hiện cả sẽ có quyền release những cái vượt quá IR với PO, như thế đồng tiền sẽ không được an toàn vì tính khách quan. Nhưng nếu để FI ghi nhận IR thì cũng khó, vì có thể IV lại chung chung cho cả nhiều hàng hóa, và sự phân bổ chi phí vận chuyển, hải quan.. cho từng loại hàng hóa theo tỷ lệ giá trị hay khối lượng là rất khó, FI khó có thể nắm bắt cụ thể được. chỉ có MM trực tiếp mua hàng mới nhận biết được khối lượng, giá trị phân bổ thể nào là phù hợp nhất.

Cuối cùng MM và FI đi đến thống nhất MM sẽ park invoice, còn FI sẽ view lại rồi post invoice để tiếp tục làm các thủ tục thanh toán tiếp theo.

Lúc hàng hóa dịch vụ mua về bên MM sẽ thực hiện việc nhập kho Dr. 152,153… /Cr. 33181000 (Phải trả người bán chưa có hóa đơn), khi có Invoice của người bán sẽ park IR để ghi Dr. 33181000, Dr.133/Cr. AP để ghi nợ người bán và thuế VAT.

Trong cách thực hiện nghiệp vụ của các kế toán trên các phần mềm khác thì việc ghi nhận hàng về đến kho là ghi nhận phải trả người bán luôn, đến lúc hóa đơn về chỉ hạch toán thêm phần thuế nữa là ok. Nhưng SAP lại có cách làm thông minh hơn bằng việc itemize thêm TK 331 trung gian “phải trả người bán chưa có hóa đơn”, rồi có hóa đơn về làm thao tác ghi nhận hóa đơn để bù trừ cho TK trung gian đó. Nếu thực tế có difference giữa invoice với purchase order một tolerance nào đấy thì SAP sẽ ghi nhận vào COGS luôn.

Về việc xuất sữa tại trung tâm vắt sữa, TT vắt sữa sẽ xuất theo delivery oder, làm GI luôn. Nhưng việc xuất hóa đơn invoice customer FI sẽ làm hay MM sẽ làm. MM làm thì sẽ liên quan đến việc sử dụng hóa đơn, quyết toán thuế của FI, nếu có sai lệch, mất mát, hỏng hóa đơn.. thì sao? MM có thế hiểu rõ pháp luật thuế để thi hành hay phớt lờ vì không hiểu tầm quan trọng của hóa đơn do nhà nước quy định. Nhưng nếu để FI làm sẽ chắc chắn không đáp ứng được hóa đơn kịp thời cho khách hàng và cho sự vận chuyển sữa trên đường.

Cuối cùng đi đến thống nhất MM làm invoice issue, kế toán sẽ bàn giao hóa đơn và hướng dẫn cụ thể, cuối tháng MM bàn giao quyển gốc và các hóa đơn hỏng, hủy… để KT kê khai với thuế.

Về chi phí trích trước 335 và chi phí trả trước phân bổ dần 142,242 SAP có cách làm rất hay và khoa học một cách tự động.

Về 335, ngày 31 hàng tháng hạch toán Dr exp/Cr 335, ngày 1 lại reverse Dr335/Cr exp rồi làm invoice vendor bình thường, như thế chỉ còn phần chênh lệch ước 335 ban đầu với invoice mới chảy vào chi phí của tháng này.

Về 142,242 trước hết lập template cho sự phân bổ chi phí này bao nhiêu tháng, rồi cuối mỗi tháng chỉ cần process SM35, clear F.13 là tự động tính chi phí vào tháng đó.

……………………….

Về việc xây dựng CC&PC structure hierarchy tưởng chừng như đã xong, các code CC & PC đã được áp dụng cho các module khác, mọi người đã quen sử dụng các code đó thay vì nói name đầy đủ. Nhưng khi configure vào hệ thống SAP lại thấy chưa hợp nhất với các công ty khác trong hệ thống. ở các công ty 2000,3000 có các CC của các phòng ban function như SD, maketting, các stores… còn Cty 1000 lại có thêm CC project. Để chỉ mục đích quản lý cho mỗi company code thì cấu trúc CC&PC cũ là ok rồi, nhưng để phục vụ quản lý chung toàn tập đoàn thì phải thống nhất CC&PC các công ty, thế là lại phải ngồi lại một lần nữa với đội tư vấn và thống nhất cách xây dựng CC&PC hợp lý nhất.

Vấn đề đánh giá lại chênh lệch tỷ giá hối đoái cuối kỳ. SAP thực hiện đánh giá tự động sẽ không cộng trực tiếp vào từng vendor, customer được, mà nó chỉ tạo đánh giá vào một cái account nào đó do mình ấn định thôi. Như vậy cuối kỳ đánh giá CLTG sẽ được ghi vào một tài khoản khác mà chúng tôi sẽ quyết định itemize thêm. Như vậy nó sẽ không có tính chất quản trị trong việc xem xét các khoản AR, AP bằng tiền nội tệ cho chi tiết các đối tượng.

Cuối cùng chúng tôi đi đến thống nhất itemize cho các tài khoản tương tự như: 131900, 331900, 144900, 244900 cho các khoản đánh giá CLTG tương tứng AR,AP, collateral. Vì không có tính chất quản trị trong chi tiết các đối tượng vendor, customer bằng local currency nên chúng tôi đã quyết định các khoản CLTG phải thu  đều được ghi nhận vào tài khoản 131900 (CLTG đánh giá lại cuối kỳ các khoản phải thu), còn các khoản CLTG phải trả, phải trả khác đều được ghi nhận vào 331900 (CLTG đánh giá lại các khoản phải trả cuối kỳ).

Khi lên bảng trial balance nó sẽ thể hiện các tài khoản đánh giá lại CLTG cuối kỳ. cái này nó không đẹp sổ sách và chưa tuân thủ đúng các chuẩn mực kế toán việt nam. Đối với VAS yêu cầu cuối kỳ đánh giá lạu CLTG phải ghi nhận trực tiếp vào các đối tượng công nợ và các tài khoản xác nhận tương ứng. nhưng SAP nó chỉ có thế thôi, không thể khác được.

Như vậy đến thời điểm này chúng tôi đã phải quyết định itemize thêm một loạt các tài khoản hơi khó hiểu đối với kế toán việt nam: TK 9942… (để allocate chi phí), 33181000 (để post GR/IR), 1319…, 1449…, 2449 …., 331900 (để revaluation Ex rate period-end), 24120008-giá trị chênh lệch nhập khẩu bò – Clearing Account (để khi thực hiện T-Code ABZON – Acquisition with automatic offsetting entry cho nghiệp vụ chuyển bò từ trại tân đáo sang các trại khác, khi các trại đã nhận được bò thực hiện T-Code F-91 để Clear 24120008 và ghi vào offsetting entry giá trị chênh lệch nếu có.

……………………….

Về xuất kho vật tư theo chế độ kế toán VN, tùy theo mục đích để hạch toán Dr. các tài khoản tương ứng, như để sử dụng cho các cost center khác nhau như xuất sử dụng trại vào TK 627, xuất sử dụng văn phòng quản lý vào TK 642, xuất để tạo ra tài sản cố định HT vào 241.

Tức là: Dr. 627, 641,642, 241/ Cr. 152,153.

Tuy nhiên trong SAP xuất kho để xây dựng tài sản: Dr. 627/Cr.152/153 (Phân hệ MM thực hiện GI), rồi phân hệ tài sản mới ghi tăng tài sản dở dang: Dr.241/Cr 627, kế toán tài sản sử dụng T-Code ABZON (Acquisition with automatic offsetting entry) trong phân hệ AA để ghi tăng tài sản. điều này nó ngược ngược với cách hạch toán thông thường. nhưng thằng SAP nó chỉ làm được thế, vì các phân hệ MM (GR/GI) và FI (AA) nó tách riêng lẻ. mà mỗi raw material khi GI sẽ được default một tài khoản expense account nhất định. Nếu không default trước thì bộ phận kho sẽ không biết tài khoản kế toán để chọn đúng.

Về xuất kho thành phẩm 155 để làm quà tặng, quà biếu freegift, donation: SAP coi nó là nghiệp vụ xuất kho bình thường và ghi nhận vào chi phí Dr. 642/Cr. 155. Nhưng ông thuế của Việt Nam lại yêu cầu doanh nghiệp phải xuất hóa đơn và tính thuế đầu ra để nộp thuế VAT output.

Nếu muốn xuất hóa đơn automatic như việc bán hàng qua SD thì phải có customer code, revenue, nhưng thật ra hàng xuất này cho biếu tặng, không nên pass qua revenue, customer vì theo chuẩn mực ghi nhận doanh thu là khoản dự định sẽ thu được chắc chắn trong tương lai, nhưng bản chất khoản này không thu được. vậy không thể thực hiện qua SD, không thể xuất hóa đơn như việc bán hàng thông thường.

Nhưng nếu làm trực tiếp FI bằng cách Dr. 642/Cr.333 sau khi MM đã thực hiện GI Dr. 642/Cr.155 thì bằng cách nào để automatic trực tiếp từ SAP ra? Và hóa đơn ghi số quantity ntn?

Đội tư vấn và ABAP lại phải design và configure hệ thống sao cho có thể in được invoice customer chỉ với cái dữ liệu Dr. 642/Cr. 333.

Lại thống nhất lại cái CC&PC structure, thêm lĩnh vực cho thuê tài sản, thiết bị – ngành nghề kinh doanh được đăng ký và phải hạch toán doanh thu 511, thay vì doanh thu khác 711.

Như vậy phải mở thêm trong cái Hierarchy CC&PC Structure cái cost center và profit center của Rental assets.

……………………….

Hợp nhất MM/FI tạo vendor master data để upload lên SAP: MM tạo vendor master data theo template rồi chuyển FI review và input các info liên quan bank key, reconciliation account, sort key.

Tạo one time vendor có 2 group code khác nhau: OTV cho External vendor, OTV cho employee.

Nhưng trong SAP lại không thực hiện được advance cho one time vendor, mà chỉ có thể advance/downpayment cho vendor thôi.

Như vậy nếu muốn thanh quyết toán tạm ứng cho employee ta phải tạm ứng cho vendor là employee, rồi post invoice cho one time vendor employee. Rồi mới quyết toán hoàn ứng cho employee, tức là advance clearance từ advance của Employee code với invoice của one time vendor.

Sau khi trao đổi và test thử, SAP có thể làm tạm ứng cho 1 nhân viên, chứng từ về hoàn ứng gồm nhiều hóa đơn của các nhà cung cấp khác nhau, nhưng vẫn có thể clear các khoản advance đó bằng cách đặt thêm mã one time vendor là employee, khi thực hiện thao tác trên clear chỉ cần input code one time vendor là employee vào field name: Other account.

Cách đặt để nhận dễ nhận biết employee như sau:

VD:       9000412 – Vendor của employee A

E9000412 –  One time vendor của employee A.

Lúc advance: ghi nợ vào vendor code: 9000412

Lúc quyết toán, post invoice: ghi vào vendor code: E9000412

Lúc clear, thì clear cho vendor 9000412, còn other account là E9000412

Cái cách này nếu post từng invoice thì có thể lên báo cáo thuế chi tiết từng invoice mà không cần phải attach file rồi xử lý manual báo cáo thuế.

Nhưng lại liên quan đến sự phân quyền authorize cho accountant park hay post. Nếu không phần quyền cho KT vừa park vừa post thì người có quyền post phải post quá nhiều trong từng document parked tương ứng each invoice.

Đội tư vấn đang view lại để make sure việc phân quyền limited cho trường hợp advance clearance for employee. Nếu không limited được sẽ không thực hiện được cách này, vì người sử dụng park invoice vendor có quyền post luôn thì cấp quản lý không kiểm soát được.

—-

……………………….

Blue print của phân hệ FI-CO đã tương đối hoàn tất, đội tự vấn FICO đang tiếp tục công việc configure hệ thống.

Đội core team FI được cấp User tha hồ mà táy máy, test thử và nghịch trên SAP data base QAS, DEV. Và có thời gian tham gia cùng nghe MM xây dựng BP và test một số T code thử.

Tuy nhiên hệ thống đang được configure nên mọi việc test thử FI còn nhiều vướng mắc, có những cái có thể test hoặc không, có những lỗi error do hệ thống chưa hoàn thiện hoặc do user chưa làm đúng process nên không complete được.

Tuy nhiên đội FI core team tất thảy mọi người đều hăng say test mọi lúc, mọi nơi, có người còn tranh thủ test cả buổi tối tại công ty, về nhà test tiếp bằng cách xin user VPN của đội tư vấn khi IT chưa phân quyền và cấp User VPN xong cho Core team.

Đội FICO team chúng tôi gồm 5 người, đã bàn giao hoàn toàn các công việc hàng ngày cho các đồng nghiệp còn lại và chuyển sang phòng Project fulltime để có điều kiện nghiên cứu SAP hơn.

Càng Test SAP càng thấy nó quá rộng, quá chuẩn, mà càng nghiên cứu chúng tôi lại thấy nó tốt, quá thông minh và hoàn hảo.

Mọi người như đang bị lôi cuốn vào trong đó, suốt ngày chỉ trao đổi, thảo luận và giải quyết các giải pháp SAP. Tuy nhiên để thực tế áp dụng được nó và khai thác được nhiều tính năng của nó cho việc quản lý Cty cần đòi hỏi một đội core team mạnh, hiểu xâu sắc quy trình để có thể training cho các enduser. Và mọi bộ phận, phòng ban phải hiểu sâu sắc về nó, cộng với các quy trình hoạt động sản xuất kinh doanh phải chuẩn theo SAP, mọi con người sử dụng nó phải hiểu sâu sắc về quy trình SAP, Blueprint của Cty và có khả năng tiếng anh tốt.

Đây là một hệ thống hợp nhất intergration, nghĩa là các bộ phận, các module, các cá nhân phải có cùng ý chí, cùng quan điểm để thay đổi toàn diện cách quản lý, cách làm việc và nhiều quy trình trùng lặp mang ý chí chủ quan hàng ngày, để cùng nhau xây dựng nên một quy trình Blueprint toàn diện cho SAP, cho Cty. Mỗi khi BP này được configure vào hệ thống, dự án vào giai đoạn golive thì sẽ mọi bộ phận, mọi cá nhân phải tuân thủ tuyệt đối quy trình SAP thì dự án mới tạm được coi là kết thúc giai đoạn 1. Các giai đoạn khai thác tiện ích của SAP còn tùy thuộc vào hệ thống hạ tầng công nghệ thông tin, nhân lực sử dụng và vận hành SAP, sự phát triển về quy mô của Cty…. Mọi việc đang ở tương lai phía trước, các cấp lãnh đạo có thể chưa lường hết được sự việc tương lai để cấu hình cho SAP chuẩn nhất.

———————————–

……………………….

Mọi T code và thao tác SAP quá cận thận, chi tiết và đòi hỏi chính xác tuyệt đối, logic đến các phân hệ khác. Tuy nhiên có một số việc đơn gian mà SAP chưa làm được, có thể do đội Core team và đội tư vấn chưa hiểu được ý nghĩa xâu xa của nó như:

–  Chạy Check lot number: Khi tạo Payment order cho cả phiếu chi cũng như ủy nhiệm chi, SAP đã không tự động running số tiến một cách tự động như các phần mềm đơn giản khác, mà ngược lại khi tạo check payment, nó chỉ cho ra cái số check number của cái check trước. rồi ta phải sửa số check đó bằng cách cộng thêm 01 đơn vị.

– Khi thực hiện T code F.13 để Clear recurring entry, mọi việc ghi nhận info, amount… vào các field cần thiết đã hoàn tất, có thể lưu trữ, post chứng từ. Nhưng nếu ta click chuột vào ô Save as complete thì mãi mãi không thể lưu trữ được. đội Core team đã mất hàng giờ để cố tìm cách sửa lỗi chứng từ, nhưng mọi việc nghiên cứu áp dụng đều không có kết quả. Và cuối cùng gõ mạnh vào phím Enter trên keyboard lại hoàn thành việc ghi nhận document đó thay vì bấm vào Save as complete như thường lệ. đúng là bó tay.

– Rồi đến việc thanh lý tài sản có ghi nhận doanh thu, khi chúng tôi vào postingkey 50 để hạch toán tài khoản GL thu nhập khác, thì việc vào một tài khoản GL bình thường Account 711, mọi kế toán đều có thể xác nhận và ghi vào bút toán hạch toán Cr. 711. Nhưng SAP nó lại khác, chúng tôi phải ghi vào tài khoản GL clearing 711910000 (Thanh lý tài sản cố định – clearing account).

Trong SAP nó ghi nhận thanh lý TS có doanh thu là TK GL Clearing để nó tự động bù trừ với tài khoản chi phí 811 là giá trị còn lại của tài sản sau khi trừ đi số tiền đã hao mòn, bút toán bù trừ này tự đống sinh ra và người sử dụng phải tick vào line item accounting entry đó để assignment thêm cái cost center muốn ghi nhận chi phí vào. Giá trị còn lại dư có hay dư nợ của TK chính 811 mới được xác nhận là P&L của việc retirement Asset with renvenue and customer, còn TK 711 clearing đã bị triệt tiêu khi hệ thống tự động hạch toán phát sinh bút toán đó.

……………………….

Intergration FICO/ MM

MM: sẽ thực hiện GR/GI và IR (park); FI review và Post IR.

– Về việc xác nhận giá trị hàng tồn kho: Theo nguyên tắc giá trị hàng tồn kho bằng giá mua gốc cộng với các chi phí liên quan như chi phí vận chuyển, thuế nhập khẩu, hải quan, vận chuyển, lưu cont, lưu bãi… liên quan cho đến khi hàng về đến kho.

Trong SAP giá nhập kho là giá theo PO, còn mọi chi phí subsequent sau PO có thể sẽ được ghi nhận vào inventory hoặc vào COGS tủy thuộc vào GR/GI, như vậy khi làm PO phải input các giá trị estismate liên quan. Có thể mua hàng của vendor này nhưng các chi phí liên quan lại của vendor khác.

Trong công việc kế toán bình thường, sử dụng phần mềm kế toán bình thường sẽ không có giá trị ước tính để nhập kho, mọi giá trị nhập kho phải có chứng từ chi phí hợp pháp, hợp lý. Nhưng trong SAP sẽ không làm thế, vì trên thực tế nếu chờ đợi các chứng từ kèm theo hàng nhập kho để cộng vào giá trị hàng nhập kho là không thể thực hiện được, vì có thể khi hàng về đến kho, xuất sử dụng xong rồi mới có các chứng từ chi phí liên quan về đến kế toán, nên kế toán sẽ không thể hiệu chỉnh thường xuyên giá trị hàng tồn kho được mà lại phải tính chi phí trực tiếp. như vậy theo chuẩn mực kế toán sẽ không phản ánh đúng giá trị đích thực của hàng tồn kho.

Trong SAP có thể ước lượng giá trị kèm theo hàng nhập kho như: chi phí vận chuyển, chi phí lưu cont, lưu bãi, thuế nhập khẩu để tính vào giá trị nhập kho. Rồi sau này hóa đơn các chi phí đó về chỉ việc nhập hóa đơn vào là OK, nếu giá trị hóa đơn chênh lệch với PO sẽ được ghi nhận trực tiếp vào COGS account 632. Như vậy giá nhập kho là chính xác dơn cách thông thường kế toán thường làm. Việc ghi nhận giá trị nhập xuất kho trong SAP có chính xác không phụ thuộc vào việc ước lượng giá trị trong PO.

Nhưng có một việc quan trọng khi ước lượng giá trị trong PO phải ghi nhận vendor. Nhưng thực tế khi ta đặt mua hàng hóa, có thể một thời gian dài sau mới làm PO/ contract vận chuyển, hoặc một vendor có thể đứng ra làm khép kín các khâu còn lại như thuế nhập khẩu, phí hải quan, lưu công, vận chuyển, bốc xếp…. nhưng hóa đơn thanh toán lại của các nhà cung cấp đó viết cho THM thay vì vendor trung gian đó xuất hóa đơn total.

Cách duy nhất THMF có thể thống nhất được với đội tư vấn và configure vào hệ thống là đặt đồng thời vendor và one time vendor cho vendor trung gian đó.

Giải pháp cuối cùng có thể thực hiện được đại khái như sau:

PO: Vendor A

Invoice: Vendor B

Làm sao để thanh toán cho Vendor A với các invoice của vendor B?

Giải pháp:

Tạo mã vendor A: 100001; tạo one time vendor B: D100001

Khi post PO: ghi nhận vendor A (PO trong SAP không thể ghi nhận cho one time vendor cũng như chi tạm ứng OTV cho Employee).

Khi post Invoice: Post cho OTV A thuộc group CPDL, khi next sang field infor vendor, ta input infor vendor B vào các field của OTV A;

Rồi bên FI sẽ thực hiện Cearing payable Vendor B với OTV A để thực hiện các T code thanh toán khác cho Vendor A.

Có một process khác trong MM mà SAP khác với kế toán Việt Nam nữa là:

Khi MM làm thủ tục mua sắm PO, rồi hàng về đến kho, nhưng vì lý do nào đó hai bên xác nhận trả lại hàng. Nhưng mọi việc hóa đơn đã OK, thanh quyết toán đã OK. Mà các bên đã thống nhất trả lại một số hay toàn bộ số hàng hóa đã nhận (Có thể do chủng loại không hợp, chất lượng chưa đạt yêu cầu….).

Về phần MM, MM sẽ làm Return PO như làm PO bình thường. Trong return PO này SAP sẽ ghi giá trị âm cho số lượng hàng hóa, còn giá trị có thể thay đổi vởi giá PO ban đầu. Lúc simulate bút toán hạch toán auto của MM nó sẽ thể hiện Cr. 152, 133/ Dr 331

Về thuế VAT phải nộp đã được bù trừ với VAT input khi nhập kho, nó ghi âm trên TK 133. Nhưng VAS lại khác với IAS ở chỗ quy định rõ rang VAT input và out put. ở VAS khi nhập kho ghi nhận toàn bộ Dr. 133 để khấu trừ thuế VAT, rồi khi trả lại phải xuất hóa đơn và ghi nhận Cr. 333 VAT output để nộp.

Như vậy nếu làm theo GI trong phân hệ MM (bằng cách lập Return PO) sẽ không đúng với VAS vì xác nhận VAT input, output ngược, IAS ghi nhận Dr. 133 (giá trị âm), còn VAS ghi nhận Cr. 333, nên số trên trial balance sẽ không thể hiện đúng với bản chất các tài khoản trong hệ thống CoA của Việt Nam.

Mặt khác ông thuế VN còn bắt buộc doanh nghiệp phải xuất hóa đơn khi trả lại hàng cho nhà cung cấp. mà trong SAP phân hệ MM không thể thực hiện được issue invoice, chỉ có phân hệ SD mới xuất được Invoice.

Vấn đề này đội tư vấn MM bó tay, chờ đợi FI, SD và intergration các module trong thời gian tới để đưa ra giải pháp tối ưu nhất.

MM thực hiện GR/IR có thể giá cả trong Invoice lớn hơn trong PO, vẫn park document được, đến lúc FI check trước khi post invoice để thanh toán vẫn có thể post được. nhưng ngay sau khi post hệ thống sẽ automatic block PO này cho việc thanh toán vì sự khác biệt đó.

Tuy nhiên FI lại có thể release block đó để tiếp tục thanh toán nếu các cáp có thẩm quyền đã approve for payment.

……………………….

Giai đoạn xây dựng BP đã tương đối hoàn thiện, nói chung quy trình Process trong FI-CO cũng gần như BP trước đây đã được ký kết. phần FI thay đổi lại hệ thống Chart of Account, cấu trúc CC&PC và một vài quy trình trong lĩnh vực nông nghiệp, trung tâm thức ăn. Phần CO bổ sung thêm 06 Blueprint (agriculture product; – Cow Standard Cost and Capitalized Expenses;  SOP and Simulative planning for cow farms and crop fields; SOP Planning for cow farm; Production Execution at Cow Farms; milking cows and  growing cows; Production Execution at Feed Center.

Đội tư vấn trở lại Sài gòn để xây dựng cấu hình hệ thống, đội Core team được cung cấp các user name để log on vào SAP và tự tìm hiểu, mày mò các T code mà test thử, mọi người hào hứng khám phá và chạy thử các T code, trao đổi bàn luận và cùng nhau giải quyết các vấn đề chưa hiểu, chưa post được một cách tích cực như chưa bao giờ được làm việc, mọi người park, post, khám phá SAP và nghiên cứu trên mạng để hiểu rõ hơn và giải quyết các vướng mắc trong nghiệp vụ kế toán, có nhiều hôm quên cả giờ nghỉ trưa đi ăn, hoặc thứ 7, chủ nhật cũng có một số Core team lên văn phòng để test thử các T code còn chưa rõ, có người còn ra quán café wifi vào buổi tối để log on và nghiên cứu SAP….

Càng Test nhiều, càng nghiên cứu kỹ càng thấy SAP là một phần mềm rộng lớn, đa dạng báo cáo, và sự lo gic của các phân hệ chức năng. Tuy nhiên để SAP vận hành được, đòi hỏi người sử dụng phải post chi tiết và chuẩn xác tuyệt đối, nhưng bút toán nào thuộc phân hệ nào, T-code nào cần phải được nhập vào đúng với quy trình, phân hệ cụ thể trong SAP thì mới có được các báo cáo chính xác và vận hành hệ thống chạy không bị lỗi.

Thỉnh thoảng có một số nghiệp vụ kế toán hàng ngày chúng tôi đang làm mà không biết cách áp dụng post vào SAP như thế nào, bằng T code nào, rồi anh em cùng thử nghiệm, cùng đưa ra các phương án để test thử, chạy thử xem nó luân chuyển, ghi nhận như thế nào vào SAP.

Ví như nghiệp vụ vốn hóa chi phí trích trước lãi vay vào tài sản Dr. 241/Cr. 335: vừa liên quan đến tài sản vừa liên quan đến chi phí trích trước. vậy nên ghi nhận bằng T-code F-90 (acquisition external with vendor, without PO) hay sử dụng T code FBS1- Accrual/deferral Acc 335??…

Trường hợp 1: nếu sử dụng F-90 thì ghi nhận vào TS là OK, nhưng đến kỳ sau có invoice về thì post invoice như thế nào để ghi nhận vào AP là tk 335. Cái này SAP không thực hiện được vì mỗi khi post invoice vendor hệ thống tự động định khoản và ghi nhận AP cho TK 331, như vậy lại phải thêm công tác manual cấn trừ giá trị 335 với 331. Cả đội core team chưa tìm ra được cách để offsetting 2 cái AP này.

Trường hợp 2: Sử dụng T-Code FBS1 tính chi phí trích trước phải trả 335, rồi kỳ sau dung F.81 Reverse accrual/deferral documents và post hóa đơn cho AP 331 bằng T-code F-90 không qua PO. Cách này có vẻ hay hơn và không phải offsetting 331/335. Nhưng đến khi test thử trên hệ thống mới thấy SAP ghi nhận chưa hợp lý với VAS lắm. ban đầu nó ghi Dr.241 bằng FBS1, rồi lại Cr.241 bằng F.81, rồi lại Dr.241 bằng F-90, giá trị 241 là đúng nhưng lên bảng cân đối phát sinh trial balance thì Total arising debit/credit lại triple. Nhưng giả sử đến kỳ sau nữa vẫn chưa có invoice về để làm theo thứ tự quy trình trên, trong khi tài sản AUC đó đã đủ điều kiện để settlement sang Fixed asset rồi thì sao? F.81 reverse cho 241? F-90 ghi tăng tài sản cho 211 hay 241.

Sau khi test thử Dr. 241/Cr. 335 T-code FBS1, rồi settlement AUC to Asset bằng Tcode AIAB, AIBU, rồi vào T code F.81 , nhưng document accrual/ deferral không thể reverse được.

Sau khi tham vấn qua CSC cách để reverse document đó, phải thực hiện 2 bước là (1) T code AIST – reverse document for capitalized AUC (trong T code này ta có thể reverse cho từng Line item, nghĩa là có thể chỉ reverse cho item accrual đã settled FA, còn các Item khác vẫn có thể giữ nguyen, nghĩa là vẫn có thể giữ nguyen nguồn gốc của tài sản cố định đó). (2) sau đó tiếp tục reverse F.81.

Giải pháp này có vẻ hợp lý đối với một vài cái vốn hóa lãi vay vào tài sản. nhưng đối với tình hình thực tế công ty, đang trong quá trình đầu tư, hàng tháng lên đến hàng trăm tỷ tiền lãi vay ngân hàng cần được vốn hóa vào giá trị tài sản của hàng nghìn tài sản khác nhau, nếu không vốn hóa vào tài sản thì phải ghi nhận chi phí hoạt động tài chính, lỗ tài chính quá cao, không thể hiện đúng kết quả hoạt động sản xuất kinh doanh.

Đến đây đội core team chỉ có thể tìm ra cách nào đó để có thể reverse một lúc nhiều cái document capitalized AUC (T code AIST), thì mới có thể áp dụng được giải pháp này cho công ty. Nhưng SAP nó lại không làm được điều đó, mà chỉ có thể reverse mỗi lần cho một asset code duy nhất, nghĩa là nếu áp dụng cách này chúng tôi phải thực hiện đến hàng nghìn thao tác reverse. Giải pháp này không khả thi, như vậy chỉ có một cách duy nhất là post F-90 để ghi tăng tài sản, và theo dõi công nợ 331 luôn. Sau này chứng từ hoặc tỷ giá tính toán công nợ nếu có khác với số liệu kế toán đã hạch toán sẽ được ghi nhận vào chi phí hoạt động tài chính luôn.<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /><o:p></o:p>

Về nghiệp vụ Ký quỹ, ký cược.

Cái T code FV65 – Downpayment  for Vendor đã được chúng tôi test đi test lại nhiều lần cả VND và USD để có số dư công nợ vendor thông thường, và vendor employee rồi mới test được một số T code khác clear invoice-downpament, advance clearance employee…

Nhưng khi nghĩ đến các nghiệp vụ hàng ngày là chi tiền ký quỹ, ký cược mà cả đội core team xài hết cả buổi, mắc như gà mắc tóc, không biết sử dụng T code nào để thực hiện nghiệp vụ. đến lúc bó tay tôi mới tham vấn đội tư vấn thì mới biết được dùng FV65 như một dowmpayment bình thường. trong đó nó có Special GL [V] – collateral.

Về nghiệp vụ Cấn trừ công nợ vendor với vendor, vendor với customer; sử dụng nó như thế nào, có người vừa là customer nhưng cũng là vendor, đặt mã khách hàng như thế nào để khi lên báo cáo AR&AP của các ông này là một….. test mãi mà chưa post được. Cuối cùng cũng phải gọi điện cho tư vấn, bật loa ngoài cho cả đội core team cùng nghe và học hỏi test thử. Nhưng vẫn bị vướng mắc nhỏ cần hợp nhất với module MM khi đặt mã code vendor/customer sao cho việc quản lý các ông vendor/customer đặc biệt này được hiệu quả nhất.

Đúng là không thầy đố mày làm nên, nhưng vướng một chút lại gọi điện hỏi ngay tư vấn thì lại càng ngại, chi bằng cứ mày mò đến lúc bó tay hãy hỏi.

Qua thực nghiệm mới nhận được cái giá trị của sự tự mày mò học hỏi, phải tự test thử, nghiên cứu thử, chạy thử các quy trình, phải tự vận động tìm tòi áp dụng các công việc hàng ngày để tìm cách thao tác trên SAP, phải tự sang tạo thêm các tình huống, các nghiệp vụ kế toán khác có thể hiện tại chưa có nghiệp vụ kinh tế phát sinh để tìm ra các giải pháp trên SAP. Tuy có thể mất nhiều thời gian hơn hỏi đội tư vấn và chờ người ta hồi đáp (vì cũng có nhưng cái chúng tôi hỏi tư vấn mà tư vấn đã vấp phải bao giờ đâu, người ta cũng phải test thử rồi mới tư vấn lại được, việc hiểu sâu sắc các nghiệp vụ kế toán hàng ngày người ta đâu có rành bằng mình).

Ta càng tự vận động càng thấm nhuần hơn cái quy trình, cái cốt lõi của SAP, càng hiểu rõ được quy trình, T code sẵn có của SAP và các quy trình mình đã configure áp đặt cho nó theo cái hoạt động sản xuất kinh doanh riêng của công ty, và theo cái chuẩn mực kế toán VAS khác với IAS. Đến đây tôi đã một phần giảm bớt áp lực cho việc golive sắp tới.

……………………….

Đội tư vấn CSC lại trở lại để training, sau khi trao đổi trực tiếp việc vốn hóa lãi vay vào tài sản cố định bằng các giải pháp trên, chúng tôi đã đi đến quyết định cuối cùng, không ghi vốn hóa quá F-90, vì như thế đã phải ghi nhận invoice vendor , accounting entry Cr. 331, nhưng như thế nó không phản ánh đúng nghiệp vụ kinh tế phát sinh.

Chúng tôi cùng đưa ra giải pháp test thử FB01 để post GL document, hoàn toàn có thể làm được trường hợp này bằng cách chọn Type = AA, và các posting key tương ứng ghi tăng hay giảm tài sản (70,75), Ttype = 100; pstkey 40, 50 ghi Dr/Cr 335.

Nếu AUC đã settlement sang tài sản và tính khấu hao trong kỳ rồi thì SAP không thể reverse chứng từ đó nữa, nhưng ta lại có cách khác là FB01 để ghi tăng/ giảm tài sản; rồi tính khấu hao ngoài để hiệu chỉnh khấu hao unplanned tương ứng tài sản đó bằng cách dung T-code ABZU _Write-Up (Manual Value Correction )với Ttype = 650 _ unplanned depreciation on current-yr acquisition để ghi tăng giá trị khấu hao hoặc ngược lại Ttype = Z65 để ghi giảm giá trị khấu hao. Trong giao diện SAP khi ta tick vào biểu tượng Ttype thường display ra tất cả các Ttype để người dùng tham khảo và lựa chọn cho đúng, nhưng trường hợp này Ttype không hiện các Ttype = 650 hay Z65, đến đây cả đội tư vấn CSC và core team cũng không hiểu được SAP vì sao lại thế. Đội tư vấn chỉ biết tư vấn cho chúng tôi giải pháp đó để thực hiện nghiệp vụ nhưng cũng không có sự giải thích nào cho điều bí ấn đó.

……………………….

Về One time vendor employee.

Tạm ứng cho cán bộ nhân viên chỉ có đặt mã CBNV là vendor, vì không thể tạm ứng cho one time vendor được, nhưng khi quyết toán hoàn ứng lại hóa đơn của nhiều vendor khác, nên đặt thêm mã one time vendor employee tương ứng để quyết toán hoàn ứng và bù trừ giữa vendor và one time vendor.

Khi đặt mã one time vendor employee, chúng tôi core team mỗi người đặt một số one time vendor employee khác nhau. Tuy nhiên đến lúc post invoice thì có mã nhân viên sử dụng được, có mã lại không sử dụng được do không hiện ra bảng kê khai các thông tin vendor invoice.

Chúng tôi loay hoay mãi, rồi đổ tội cho lỗi phần mềm, chắc là phần mềm chưa configure xong hệ thống. mọi người chỉ chú tâm test vào cái mã nhân viên đúng đó.

Đến lúc có bạn trong nhóm support FICO chỉ ra lỗi khai báo master data one time vendor là phải bỏ trống field [ref.acct group], chúng tôi mới hiểu được vấn đề do core team mò chưa hết. đúng là giao diện quá nhiều field, nếu cứ entry đủ dữ liệu cho các field ấy có thể sẽ không chạy được.

Về việc Clear bank check.

Nguyên tắc cơ bản trong việc chi thanh toán trong SAP là: (1) hạch toán chứng từ thanh toán, có thể là downpayment hay outgoing payment bằng tài khoản clearing (tài khoản clearing cũng là 111,112 nhưng cuối cùng bằng số 1, và cũng có thể hiểu số dư của nó thể hiện tiền đang chuyển; (2) tạo check thanh toán; (3) in phiếu check, có thể bằng ủy nhiệm chi, có thể bằng phiếu chi; (4) sau khi ngân hàng thực sự chuyển tiền hoặc khách hàng ký nhận tiền mặt, kế toán mới thực hiện bước tiếp theo là clear để Dr. TK bank account, Cr. Bank account clearing.

Nguyên tắc là mỗi nghiệp vụ chuyền tiền đã được xử lý đều phải clear khoản tiền đang chuyển sang tiền đã chuyển. nhưng thực tế diễn ra hàng ngày hàng trăm cái check cần xử lý, hàng tháng có thể lên hàng nghìn cái check cần xử lý và clearing. Đội core team đã tìm ra được phương án clear một nhóm check, có thể mỗi tài khoản chỉ cần thực hiện một lần clear cho cả tháng khi nhận được sổ phụ của ngân hàng bằng một sự mày mò thử nghiệm hết sức thủ công và sâu sắc như sau.

Vào T-code FCHN- Check register để xem trạng thái của các check. Tại cột cuối cùng của layout [encash/voice] có thể hiện ngày tháng encashment check, trong đó có những check không có ngày tháng nó thể hiện check đó chưa được clear hoặc void payment. Ta sẽ thấy có các check rời rạc chưa được clear, vấn đề quan trọng nhất là làm sao group các check này lại để tiếp tục tìm phương pháp clear group nhanh nhất.

Click con trỏ chuột vào một ngày bất kỳ trên cột đó, rồi double click biểu tượng Set filter để lọc theo ngày encashed/voided = 00.00.0000, click vào biểu tượng Multiple selection để tiếp tục điền vào single value = 00.00.0000, execute để lọc được các check clear có ngày tháng 00.00.0000 nghĩa là chưa được clear.

Open T-code FCHR để clear check, copy group cash chưa được clear đã view được ơ trên để clear toàn bộ bằng một lần duy nhất.

……………………….

Hôm nay có đội tư vấn CSC ra để tiếp tục training và giải quyết các khúc mắc trong gia đoạn vừa rồi, chúng tôi xem xét lại và thống nhất được một số vấn đề như asset class, tài khoản xác nhận doanh thu một số sản phẩm khác là 511 hay 711, rồi lại mở chi tiết cho TK 711, ghi nhận chi phí vào cost center head office hay vào các cost center cụ thể….; rồi cách tính ngày khấu hao như thế nào (hiện tại hệ thống tính ngày khấu hao đầu tháng của phát sinh tài khoản, và tính thanh lý, bán tài sản vào ngày đầu tháng sau), tuy nhiên theo luật việt nam, ngày tính khấu hao, thôi tính khấu hao tại ngày ghi nhận hoặc bán tài sản, tức là tính khấu hao theo ngày. Sự quyết định thay đổi tại công ty 1000 ảnh hưởng đến dữ liệu Cty 2000,3000 trong năm vừa qua. Nên đội tư vấn lại phải tìm cách configure hệ thống cho Cty 1000 và hiệu chỉnh cho Cty 2000, 3000.

Đội core team lại quay lại vấn đề vốn hóa lãi vay vào tài sảnm, hoặc trích trước một loại chi phí vào giá trị tài sản. vẫn quay lại vấn đề cũ chưa được giải quyết ở trên là:

Tạm tính chi phí trích trước sử dụng T code FBS1, sau đó reverse F.81, nhưng nếu AUC đã settled sang FA thì không reverse accrual/deferral F.81 được mà phải vào T-code AIST để reverse AUC capitralized FA trước, rồi mới dùng F.81. nhưng nếu FA đã tính khấu hao rồi thì không thể là AIST được nữa, mà phải dùng FB01 để post các bút toán liên quan. Nhưng thực tế chức năng của FB01 quá mạnh, có thể làm rất nhiều nghiệp vụ thay vì sử dụng các T code cụ thể, nên cái T code này sẽ bị hạn chế đến hầu hết các end user, chỉ có 1 hoặc 2 core user mới được phân quyền sử dụng T code này.

Đội core chúng tôi đã test thử và đưa ra các tình huống về ghi tăng, giảm tài sản khi có invoice hoặc trích trước 335, chỉ dùng T code F-90. Và mọi việc đã thành công. F-90 có thể làm được Dr.241/Cr 331, Dr.331/Cr 241; Dr 241/Cr 335, Dr.335/Cr.241 bằng các cách chọn document type riêng và posting key riêng. Sau khi test thử nghiệm và kiểm tra lại khấu hao chúng tôi thấy SAP tính bù trừ tiền khấu hao rất chuẩn, nó tính bù trừ khấu hao của các tháng trước vào ngay tháng hiệu chỉnh nguyen giá FA luôn, còn các tháng sau bằng chính khấu hao của tài sản sau khi hiệu chỉnh giá trị.

……………………….

Hôm qua đội tư vấn CSC training về T code thuế VAT khấu trừ, đến cuối buổi chiều tôi mới nhận được sự phản hồi của kế toán thuế của mình là bảng kê thuế  không diễn dải dòng text nội dung hóa đơn. Sang nay tôi cùng 1 người bạn trong nhóm core team và một người của đội tư vấn cùng xem xét và test trên 1 máy tính để tìm nguyên nhân vì sao dòng diễn giải nội dung hóa đơn lại không thể hiện nội dung được post trong hệ thống. tuy nhiên đến chiều vẫn chưa ra được cái báo cáo thuế VAT đầy đủ như yêu cầu của thuế. Chúng tôi tạm gác lại để đội tư vấn nghiên cứu tìm giải pháp configure hệ thống, để quay sang thiết lập cấu hình báo cáo lưu chuyển tiền tệ Cashflow.

Trong hệ thống SAP standard không có báo cáo lưu chuyển tiền tệ như mẫu báo cáo việt nam, đội ABAP tư vấn đã thiết kế template cashflow và thiết lập các công thức, cách thứ nhặt số liệu tự động rất tốt. tuy nhiên để ra báo cáo này thật chuẩn, không thiếu sót bất cứ các khoản chi nào vào báo cáo lưu chuyển tiền tệ đòi hỏi mọi nghiệp vụ hạch toán liên quan đến tiền tệ phải được lựa chọn đúng field text để xác nhận khoản chi hay khoản thu tiền tệ đó thuộc loại nào, code nào trong các code lưu chuyển tiền tệ. thự tế giao diện SAP để nhập diễn giải vào các document rất dễ nhầm lẫn, vì nó có 01 field trống text, người nhập vào sẽ input ngay diễn giải riêng của mình để chứng từ thêm dễ hiểu và báo cáo chi tiết cũng rõ rang hơn. Nhưng SAP nó lại không nhặt những diễn giải đó lên BC LCTT, mà ta phải chọn diễn giải và mã trong SAP đã mặc định, rồi tiếp đó có cái dấu hiệu long text mới bấm vào để viết diễn giải.

Chúng tôi đã thử nghiệm nhập chứng từ, post, và báo cáo thuế để tìm ra được cái sâu xa đó của SAP,  được giải pháp đó lại liên quan đến cái diễn giải trong template accounting entry được thiết kế từ trước, tuy nhiên cái này không khó khăn đối với đội ABAP.

Vấn đề là training cho end user để lựa chọn đúng các chỉ tiêu khi hạch toán, nhưng thực tế có phải kế toán nào cũng đủ trình độ, suy luận để gắn kết các nghiệp vụ kinh tế phát sinh thực tế vào các chỉ tiêu đúng của báo cáo lưu chuyển tiền tệ đâu. Vấn đề này là giải pháp cuối cùng nhưng tôi vẫn thấy lo lo cho sự vận hành sau này, và sự kiểm soát chưa chặt chẽ của người có quyền post.

Chiều nay đội FICO không phải training, tôi rủ các bạn FICO sang nhóm MM để nghe training, vô tình tôi được học rất nhiều thứ từ các T code nghiệp vụ đề nghị xuất kho, xuất kho, kiêm tra kho, in phiếu xuất kho, xuất hóa đơn và ghi nhận hạch toán tự động vào phân hệ kế toán, ghi nhận vào các cost center.

Trước đây có vài buổi hợp nhất MM-FI chúng tôi có thảo luận phương pháp hạch toán kế toán trên lý thuyết, nhưng đến nay mới thật sự hiểu được SAP ghi nhận vào hệ thống các bút toán và các tài khoản mà trước đây tôi đã tạo ra Chart account và định hướng hạch toán tài khoản tương ứng, ghi nhận vào các cost center nào rồi sau này sẽ phân bổ như thế nào.

Tôi đã có cơ hội để thuyết trình CC&PC hierarchy structure, bộ phận kho cũng tranh luận và hỏi rõ nhiều vấn đề liên quan đến cost center rất sôi nổi, tôi thật sự cảm thấy vui khi được giảit rình cho mọi người rõ hơn về cách ghi nhận chi phí và lãi lỗ, phân bổ chi phí trong SAP mà chúng tôi FICO đã cấu hình.

Và cũng rất vô tình tôi nhận ra trong phân hệ MM, thủ kho có thể xuất kho cho tiêu dùng nội bộ hay cho biếu tặng… theo cách quản lý thông thường ngoài, và chỉ cần nhận yêu cầu xuất kho mang tính nội bộ trong hệ thống SAP là thủ kho có thể xuất kho ngay thành phẩm và ghi nhận chi phí tiêu dùng nội bộ hay biếu tặng. mà theo luật thuế thì các thành phẩm xuất kho cho các lĩnh vực đó đều phải xuất hóa đơn tài chính với giá bằng giá bán và nộp thuế VAT đầu ra bình thường như trường hợp bán hàng.

Như vậy trong quản lý hàng tồn kho chúng tôi phải thay đổi lại một quy trình nhỏ là xuất cho các mục đích trên phải qua kiểm soát FI để kịp thời xuất hóa đơn đỏ lẻ để kê khai nộp thuế.

Vậy là cả nhóm MM-FI-Tư vấn lại mò mẫm để tìm ra giải pháp, tìm cách lọc các phiếu xuất kho cho các mục đích đó bằng movement type tương ứng rồi thống nhất cuối mỗi tháng kế toán check lại phân hệ xuất kho và xuất hóa đơn hạch toán trực tiếp tại FI.

……………………….

Hệ thống SAP không có báo cáo lưu chuyển tiền tệ Cash flow như template của việt nam, đây là một báo cáo bắt buộc khi nộp báo cáo tài chính. Thành viên phụ trách ABAP của đội tư vấn đã thiết lập xong trên hệ thống và chúng tôi đang xem xét lại, test thử để xem các chỉ tiêu trên báo cáo có đúng với các phát sinh thực tế không.

Báo cáo rất đẹp và đầy đủ, dễ dàng kiểm tra các số liệu bằng cách chỉ cần double click ra ra các chứng từ chi tiết như các phần mềm kế toán khác, và nó cũng khác biệt với tất cả các báo cáo khác standard của SAP.

Tuy nhiên để báo cáo này nhặt đúng, đủ số liệu thu chi tiền thì điều quan trọng là người sử dụng phải vào đủ chỉ tiêu ID trong text của chứng từ. nếu khi post chứng từ nếu không chọn text là ID (để ấn định khoản thu, hoặc chi đó cho mục đích gì, chọn mã số để SAP total lại các mã số đó vào các chỉ tiêu trên báo cáo đã được configure tương ứng).

Thông thường enduser không hiểu được ý nghĩa của ID đó rồi nó sẽ nhảy vào cash flow như thế nào, nên sẽ viết diễn giải chi tiết trên text đó như các giao diện, các phân hệ post khác. Tuy nhiên cái cấu hình báo cáo này là do đội ABAP tự design và ấn định cho SAP nhặt các chỉ tiêu do người post ghi nhận, nên điều quan trọng nhất là người post phải ghi nhận chính xác tuyệt đối các nghiệp vụ kinh tế phát sinh vào các chỉ tiêu báo cáo cash flow nào.

Một điều quan trọng nữa trong báo cáo được customize này nữa là nó có thể cho ta biết được nhưng khoản chi, thu nào đã chưa được ghi nhận vào cash flow do chứng từ post chưa chọn ID hoặc chủ động viết text diễn giải vào thay vì chọ ID tương ứng. chỉ bằng thao tác click chuột là sẽ display các chứng từ đó để người lập báo cáo dễ dàng hiệu chỉnh ID chứng từ.

Nhưng có một điểm làm mất thời gian của người sử dụng là, các bút toán clearing tự động Bank reconciliation nó sẽ không thể hiểu ID nào, và chắc chắn không auto chọn ID được. nếu người lập báo cáo mà lọc các bút toán này để hiệu chỉnh ID thì báo cáo Cash flow sẽ bị double vừa thu vừa chi. Hoặc là các nghiệp vụ mua bán ngoại hối vừa ghi nhận tăng loại tiền này vừa ghi nhận giảm loại tiền khác, người lập cash flow phải hiểu bản chất của cash flow để loại bỏ các chỉ tiêu này ra khỏi cash flow report.

Giải pháp cuối cùng là đào tạo cho enduser hiểu các chỉ tiêu trên báo cáo lưu chuyển tiền tệ và phải luôn luôn chú ý lựa chọn ID vào text khi post chứng từ. rồi cuối kỳ người lập báo cáo kiểm tra lại các chứng từ chưa có ID, hoặc chọn ID sai để correct ID đúng chỉ tiêu nghiệp vụ kinh tế phản ánh. kiểm tra các bank reconciliation , các chứng từ mua bán ngoại hối Foreign exchange contract đã post ID để bỏ ra tránh double vừa thu vào vừa chi ra trên báo cáo lưu chuyển tiền tệ.

……………………….

Hôm nay là buổi thứ hai training module CO, một ngày làm việc quá căng thẳng, chúng tôi được tiếp cận cách upload AOP, lập rule phân bổ chi phí, lập kế hoạch quantity, tính giá, và ước lượng chi phí planning.

SAP có một thế mạnh là phân bổ và tính giá thành tự động khi ta đã thiết lập cho các rules phù hợp. Ta có thể group cost center, group cost element để phân bổ cho từng nhóm.

Mô hình hoạt động sản xuất kinh doanh của THM quá rộng, đa dạng và nhiều lĩnh vực, gồm cả chăn nuôi, trông trọt, đầu tư xây dựng, sản xuất kinh doanh, cho thuê tài sản, dịch vụ garage…. Trong các cost center lại có nhiều chi phí chung chung general admin, rồi lại logistic có cả các cost center riêng. Việc phân bổ chi phí thực tế quá phức tạp và chưa thống nhất được phương pháp phân bổ nào phù hợp nhất, xét trên tiêu chí tiêu hao chi phí hoặc doanh thu sinh ra tại các cost center là rất khác nhau giữa trồng trọt, chăn nuôi, đầu tư xây dựng… nên việc chọn tiêu thức phù hợp là rất khó.

Mặt khác nếu cộng dồn các chi phí để phân bổ cho các cost center thì đơn giản hơn chút ít, nhưng mà ở các cost center nhận sẽ không chi tiết được chi phí được phân bổ thuộc loại chi phí gì nên để ban quản trị phân tích các yếu tố cấu thành lên sản phẩm là rất khó khăn, có thể phải làm ngoài hệ thống.

Ví dụ để tính 1 lít sữa được sản xuất ra cần bao nhiêu chi phí nhân công, ta phải tính được CPNC được phân bổ từ field crop; garage, mainternance, logistic, head office và các chi phí nhân công tại trại (chi phí này lại được phân bổ theo số lượng bò milking cow hay cow AUC).

Sự phân bổ chi phí có tính trừu tượng cao, đòi hỏi phải nắm rõ logic luân chuyển chi phí, và dựa vào tiêu thức thích hợp cho từng khúc đoạn phân bổ (có lúc theo tỷ lệ overhead_627, có khúc đoạn theo tỷ lệ %, có khúc đoạn phân bổ đều, có khúc đoạn lại theo số lượng bò…).

Khi đã có cái nhìn bao quát rồi mới có thể xây dựng được Cycle và segments assessment để chạy phân bổ.

Chiều nay nhận được master data Material của bộ phận MM chuyển sang gồm khoảng 2000 items, để kế toán attach cho một cái valuation class tương ứng với mỗi Items, rồi các valuation class này sẽ được configure vào hệ thống để khi MM thực hiện nhập xuất kho GR, GI sẽ tự động ấn định tài khoản hàng tồn kho và chi phí sang phân hệ kế toán.

Đến đây tôi mới thực sự hiểu được mối liên kết gắn bó và quan trọng bậc nhất của việc xây dựng COA ban đầu đến nay nó gắn kết với phân hệ kho của bộ phận MM như thế nào, MM có cách theo dõi riêng từng material group, kế toán phải xem xét nó và ấn định cho nó các tài khoản kế toán tương ứng.

Cách tính giá material có 2 cách là giá V – giá mua thực tế hay giá S- giá standard. Nên phải phân biệt được các material của MM là mua ngoài hay là từ semi finish goods, finish goods.

Vì quy trình sản xuất của Cty gồm nhiều phân đoạn nên giá thành nhiều phân đoạn, đồng nghĩa với các bán thành phẩm, thành phẩm nhiều loại.

Nói tóm lại phải mò mẫm khoảng 2000 material để gán cho chúng đúng valuation class, giá price control, và phải làm từng bảng cho từng plant khác nhau. Mỗi plant có thể chỉ có loại material này mà không có loại khác, tùy theo tính chất sản xuất và quy trình trên các khúc đoạn sản xuất kinh doanh.

……………………….

SAP đang trong thời điểm gấp rút để test integration tất cả các bộ phận trên data blank. Nên các Module đều phải làm việc rất căng thẳng, thêm vào đó mỗi cá nhân trong core team đã nhận thấy trách nhiệm gánh nặng của mình để vận hành SAP sắp tới golive.

Mọi issue đều được giải quyết thông qua các cuộc họp giữa đội core team, đội support và đội tư vấn CSC. Tuy nhiên mấy ngày vừa qua có nhiều sự xung đột giữa đội tư vấn và support, core team, nhất là trong phân hệ CO, thời gian training quá ngắn mà công việc lại nhiều, cách tính cost lại phức tạp và trừu tượng nên mọi người vẫn chưa được clear vấn đề này lắm, kể cả trong các thuật ngữ, các khúc đoạn công việc segment, cycle, activity type, cost component, cost element …. Mọi thuật ngữ đều mới mẻ và rất trừu tượng để hiểu rõ đường đi nước bước của SAP.

Mình phụ trách chính mảng FI nên phải cố gắng test càng nhiều càng tốt và tìm ra các tình huống scenarios để note lại và đề nghị đội tư vấn giải quyết.

Có một số scenario mà đội tư vấn chưa từng gặp như việc vốn hóa lãi vay vào giá trị tài sản, việc kiểm soát lại bộ phận MM trong GR/GI các material khi chẳng may material đó chính là tài sản cố định mà bộ phận MM lại coi là material công cụ dụng cụ, đồ dùng hay phụ tùng thay thế chẳng hạn. Mình đã mò ra được cách kiểm soát bằng cách vào báo cáo kho MB52 để lọc ra những vật tư có đơn vị là EA rồi lần theo PO để xem hồ sơ gốc và xác định có phải tài sản cố định không, nếu đúng là TSCĐ thì vào xuất kho MIGO để xuất ra làm tài sản cố định. Mình đã mò mất gần 1h để có thể làm được GI ghi nhận Dr.211/Cr.153 để summary thành từng step như: (Dr. 211/Cr.152): [A07: Good issues], [R10-other]; GI for Asset [241_consumtion for asset from warehouse]; in Tab_Material: input (*****) need to transfer; Enter; then screen layout will appear  Tab [Account Assignment], then entry [G/L account] = 211; [asset] = asset code; Tab_quantity: entry Quantity of material need to transfer asset; Tab_where: [movement type]=241; [plant]=plant of material; [storage location]=SLoc of material; Click [Check], if System inform that “Document is O.K” then click [post].

Khi đã nghi ngờ material code trên bước MB52 là TSCĐ thì thực hiện việc xuất nó ra khỏi kho thành TSCĐ, đòi hỏi phải có field G/L account để khai báo TK 211 và Field asset để ghi nhận vào asset code nào. Công việc tưởng chừng đơn giản khi  chọn movement type là 241- consumtion for asset from warehouse, nhưng thực tế layout screen cũng chẳng có cái field nào như thế để kê khai. Sau nhiều lần test mình đã mạnh dạn thử input mã material vào tab material rồi gõ enter. Thật tuyệt diệu, mà hình tự nhiên sinh ra thêm cái tab là Account Assignment. Phù phù…. Thở phào nhẹ nhõm đã có cách để kiểm soát hàng tồn kho là tài sản rồi.

Nhận được bản Master data vendor của bộ phận MM chuyển sang, rồi đến FI review và điền thêm các chỉ tiêu của FI vào danh sách vendor đó. Một danh sách các nhà cung cấp gồm hàng nghìn vendor mà MM đã summary lại từ danh sách vendor của kế toán, của các bộ phận khác, của các nhân viên khác trong phòng purchasing. Nhưng toàn bộ tên của vendor lại viết không tiếng việt không có dấu. như vậy đến khi in ra ủy nhiệm chi thì ngân hàng làm sao mà chuyển tiền cho nhà cung cấp được.

MM lại làm lại gần như từ đầu master data vendor.

Làm lại xong hoàn thiện chuyển cho FI, nhưng mà FI kiểm tra xong lại có quá nhiều sự lẫn lộn giữa nhà nhà cung cấp nước ngoài, nhà cung cấp trong nước lẫn lộn các mã code đã quy định riêng, và có quá nhiều one time vendor là employee, hoặc là cũng 01 nhà cung cấp lại có đến 3-4 cái mã code liền. FI trả lại cho MM và cuối cùng đưa đến thống nhất: chỉ lập master data cho các vendor đang có số dư công nợ tại phần mềm kế toán hiện dùng, rồi add vào các mã one time vendor là các employee cán bộ nhân viên thường ứng tiền chi tiêu thôi. Sau này có phát sinh các vendor mới sẽ create manual sau. Để tránh trùng lặp vendor và mã code quy định.

Về material master data cũng vậy, MM thỉnh thoảng lại có một version mới về sự hiệu chỉnh các master cho các plant, rồi làm khổ FI lại phải rà soát lại để lập valuation class chính xác nhất.

Theo lịch trình hôm nay đã phải integration test để 1/11/2011 sẽ golive. Nhưng thực tế vẫn chưa thể làm được khi các master data material và vendor cũng chưa xong.

Rồi lại đến việc training cho end user. Hôm nay boss của mình đề nghị mình lập kế hoạch training cho các end user trong phòng. Mình đã có kế hoạch này từ các tuần trước và lấy ý kiến các end user về thời gian, địa điểm, các facilities khác. Tất cả mọi người đều bận, và công việc quá nhiều, không thể tham gia training vào giờ làm việc được. vì vậy kế hoạch training sẽ chỉ thực hiện được vào các buổi tối, thời gian bắt đầu từ thứ 2 tuần tới, địa điểm có thể tại văn phòng công ty, hoặc tại nhà trọ của các anh em trong phòng.

Thời gian và tiến độ đến nay đã quá gấp, mình đã cảm thấy sự lo lắng bồi hồi cho thời điểm golive sắp tới. một mặt lại mong chờ ngày đó để xem dự án nó chạy đến đâu và sự thay đổi toàn diện trong cách quản lý tài chính kế toán như thế nào. Mình thật sự mong chờ ngày golive sắp tới và bằng cách cố gắng, nỗ lực hết mình trong việc nghiên cứu SAP trong giai đoạn này để kịp khắc phục, giải quyết khi còn có đội tư vấn và đội support bên cạnh.

……………………….

Chỉ còn 3 tuần nữa là đến ngày Golive theo kế hoạch, trước ngày Golive khoảng 1 tuần phải khóa sổ kế toán hiện tại, mọi dữ liệu được kết xuất ra và upload lên SAP, còn các chứng từ khác sẽ tạm hoãn lại để 01/11 bắt đầu golive rồi post lên SAP luôn.

Mình đang chuẩn bị tóm tắt quy trình FI và các bài đào tạo cần thiết để sang tuần bắt đầu đào tạo cho end user. Lịch đào tạo từ 10-21/11 gồm cả thứ 7, CN, ngày thường làm đào tạo từ 6.30 pm đến khoảng 8.30 pm, còn thứ 7,CN ở lại công ty đào tạo cả ngày. Vì buổi ngày tất cả các kế toán viên đều bận nên không thể tổ chức học được, chỉ có thểm tham gia vào buổi tối thôi. Mọi người đều nhất trí cố gắng, còn xếp mình cũng hết sức ủng hộ, và yêu cầu mình có kế hoạch, thời biểu rõ ràng để thông báo cho mọi người, và phòng hành chính nhân sự để đăng ký xe đưa đón, ăn tối tại cơ quan, và đăng ký phòng đào tạo và các phương tiện tiện dụng khác. Ngoài ra mọi người còn được tính cả thời gian làm ngoài giờ.

Hy vọng sau thời gian training này các kế toán viên có thể nắm bắt được công việc của mình, đảm bảo golive SAP thành công.

Mình cũng mới lần đầu tiên tham gia vào SAP, mới chỉ giai đoạn Blue print, chưa chạy Golive lần nào nên kinh nghiệm cũng chưa có, mới chỉ nắm bắt được các quy trình SAP và tự luyện tập, tìm tòi học hỏi các T code cần thiết và test thử thôi. Nhưng mình sẽ cố gắng đào tạo các bạn càng nhiều càng tốt để các bạn có thể hiểu được hệ thống, làm việc và có sự sang tạo trong việc nghiên cứu các T code mới hoặc trong sự vướng mắc trong công việc. có như thế mình mới có được thời gian để tiếp tục nghiên cứu sâu hơn về SAP. Nếu các nhân viên của mình chưa được đào tạo trình độ cần thiết để thực hiện công việc được giao thì mình lại phải đảm trách xử lý các công việc đó, như thế đồng nghĩa với tự bó hẹp mình trong một góc nhỏ bé của SAP.

Tôi muốn học SAP, nghiên cứu SAP ngoài việc phục vụ cho công việc, phục vụ cho việc đào tạo lại nhân viên làm việc tốt hơn, đảm bảo hoàn thành công việc của phòng và đảm bảo cho SAP golive thành công tốt đẹp còn là học cho chính mình, nâng mình lên một tầm cao mới, và tôi luôn luôn quan điểm rằng “cái hiện tại chỉ là nhất thời, sáng tạo mới là cái quyết định ai hơn ai”.

10/10/2011

Hôm nay là ngày đầu tiên theo lịch training cho các end user, nhóm FI mình gồm có 8 người, cộng thêm các bạn CO, IT và support nữa là 12 người. hết giờ làm việc buổi chiều bọn mình nghỉ giải lao đi ra hồ bơi công ty ngồi nói chuyện tào lao để chờ nhà bếp dọn cơm ăn, ăn xong tại căng tin rồi lên training.

Mình đã đứng lớp training cho các bạn từ 7h đến 8.30h không nghỉ, training một mạch, mọi người rất chăm chú nghe, đó là sự động viên lớn nhất cho mình. Mình đã over view và back ground SAP trước rồi đến giới thiệu các module FI-Co-MM-SD, chart of Account, các điểm khác biệt CoA trong SAP và CoA hiện tại, một số account khác biệt với chuẩn mực kế toán việt nam…, rồi đến giới thiệu Cost center và profit center, trong đó có dự định CC& PC cho tương lai, định nghĩa CC, PC và cách ghi nhận chi tiết chi phí vào các CC, PC cho các nghiệp vụ kinh tế phát sinh hàng ngày. Tiếp đến nói đến mối quan hệ giữa FI-CO-MM-SD và cách hạch toán, post chứng từ từ các phân hệ nó chạy về FI document như thế nào, cách giảm thiểu công việc mà SAP sẽ làm thay vì các công việc trùng lặp hiện tại…. tiếp đến mình cũng đã đề cập cụ thể các trường hợp PO, release freight, import tax… các trường hợp FI kiểm soát ngược lại MM và SD…. Cuối cùng mình nói qua các phân hệ kế toán sẽ training cho các ngày sau là AR, AP, AA, bank, và các trường hợp đặc biệt.

Continues……..

Mấy hôm nay triển khai training cho End user bận rộn quá, mỗi ngày ngồi máy tính 12h liền mà vẫn thấy công việc đang dở dang trước mắt quá nhiều, buổi ngày vừa chuẩn bị tài liệu để tối training cho end user vừa phải làm các công tác chuẩn bị cho việc upload số liệu sắp tới, và cũng phải tiếp tục test trên data integration, số liệu test hợp nhất của các module đã OK, còn việc tính giá thành đang tiếp tục hoàn thiện các khúc đoạn, các plant, profit center.

Đội ABAP đã hoàn thiện design hóa đơn để test thử các trường hợp bán hàng qua SD thì chạy ro ro, ngon lành ngay, nhưng mà đến khi test thử trong trường hợp hàng xuất free gift, donation hay xuất for consuming internal admin, nhưng trường hợp này WM khi xuất kho đã hạch toán Dr.642/Cr.155 (xuất trực tiếp từ WM mà không qua bộ phận SD). Vì vậy kế toán phải kiểm soát được các mục đích xuất này để xuất hóa đơn hạch toánDr.642/Cr.333.

Dùng FV50/FBV0 để post G/L với vài cái note outstanding như: Doc. Type = SA; line item 1: G/L Acc = 642…._Debit; Amount = Tax output only; Cost Center; Tax code = o02 (VAT output 10%); long text; Qty; Base unit; materiall; line item 2: G/L acc = 333….; Enter; double click line Acc 333; [base amount]= Net amount (value goods issue before VAT), [tax code], long text, back, post, enter. (mục đích để làm billing trực tiếp từ FI có thể in ra được đầy đủ nội dung như từ SD)

Còn việc xuất hạch toán và xuất hóa đơn cho các mặt hàng là sản phẩm phụ không chịu thuế VAT đầu ra như bút toán Dr.131/Cr.711: Dùng FV70/FB70 để post, một vài điểm lưu ý sau: Tab_ basic data: Amount; do not mark [calculate tax]; choose [Output tax 0%]; Bus.place/sectn=1000; G/L account= 71180000-Credit; Cost center; Tax code; Long text; Material; Tab_Details: Header Text = Series&No invoice issue–> for tax report.

Trong cái field [calculate tax] nếu mark vào thì đến lúc simulate hóa đơn cũng chẳng có dữ liệu, hoặc là nếu không chọn VAT output = 0% thì cũng chẳng in được hóa đơn. Cái này tôi chẳng hiểu vì sao, chỉ biết là đội ABAP làm xong và tư vấn cách sử dụng như thế thôi.

Số liệu sau khi test integration tương đối đồng nhất giữa plan và actual. Tuy nhiên số variance của Bò lại chênh lệch quá cao, vì số lượng và giá trị bò khổng lồ hàng chục nghìn con, tương đương hàng chục nghìn cái tài sản. có 3 phương án xử lý chênh lệch này cuối mỗi tháng, (1) phân bổ vào AUC, (2) phân bổ vào từng FA_ mở sub asset cho từng loại FA, (3) phân bổ vào 1 FA mới để tính khấu hao riêng_ coi như toàn bộ khoản chênh lệch này là một tài sản. sau khi thảo luận, trao đổi những ưu điểm nhược điểm các phương pháp, công sức kế toán phải làm cho mỗi tháng so với giá trị quản trị thu được từ sự phân tích số chênh lệch đó.
–          AUC bò được tính theo giá standard cost, hàng tháng sẽ không có sự thay đổi standard cost đó, thay vào đó, mỗi 6 tháng hiệu chỉnh standard cost một lần dựa trên cái chênh lệch Std với actual. Như vậy cái số liệu variance hàng tháng sẽ được phân bổ vào fixed asset.
–          Nếu mở ra cho mỗi asset với 1 sub asset thì cũng có thể phân bổ vào từng sub asset này được để quản trị có thể xem được tách biệt giá standard fixed asset cow với cái variance, nhưng sự bất lợi là tăng khối lượng công việc của kế toán quá nhiều trong việc entry số liệu vào cuối tháng , (lúc retirement, transfer, settlement, hoặc die các loại bò milking cow… hệ thống có thể upload từ Afifam và automatic trong hệ thống các Main asset, nhưng còn sub asset kế toán phải làm manual tương ứng cho từng trường hợp thanh lý, chuyển, chết…
–          Nếu xem xét toàn bộ variance ấy là một tài sản để tính khấu hao thì công việc sẽ giảm thiểu thời gian hơn mà tránh được các sai sót khi hiệu chính giá. Nhưng như vậy bên Planing và CO sẽ không xem xét được variance của từng loại mà phải thực hiện phân tích ngoài cho cái variance đó.

15/10/2011
Hôm nay thứ 7, như thường lệ khối văn phòng được nghỉ, tuy nhiên nhóm FI vẫn phải làm việc cả ngày thứ 7 và chủ nhật để kịp tiến độ dự án.
Trong quá trình training lại nảy sinh một scenarios như sau: Nhà cung cấp xuất hóa đơn bổ xung tiền thuế, hóa đơn chỉ ghi bổ xung thuế mà không có số lượng đơn giá hàng hóa. Kế toán phải hạch toán Dr. 131/Cr.331. chúng tôi test thử như sau:

Solution 1:
Step 1: FV60 để park invoice vendor à SAP ok ghi nhận parked document.
Step 2: FBV0 để post document đó à Nhưng SAP not available.

Solution 2: FB60_ enter vendor invoice àSAP OK
????? I don’t understand right now.

16/10/2011
Hôm nay chủ nhật nhóm FI team training cả ngày xong được phần AP và một phần của AR, hai ngày thứ 7 và chủ nhật là cả không gian và thời gian riêng cho FI team, nên mọi việc training, tranh luận có hiệu quả hơn rất nhiều so với ngày thường

Tuy nhiên với End user đấy lại là một sự quá tải, những thông tin, T code, nghiệp vụ chúng tôi truyền đạt lại đều là những cái mới mẻ đổi với End user. Cứ đến cuối mỗi buổi chiều các end user lại loạn hết cả lên, chằng nhớ nổi quy trình nữa, có khi còn nhầm T code downpayment sang incoming payment, outgoing phayment.

Đến nghiệp vụ clearing, chuyển công nợ, tôi tóm tắt và đưa ra các tình huống thực tế đang diễn ra tại công ty để mọi người có thể hiểu cái process trước, rồi mới nói đến sử dụng T code nào. (1)Chuyển nợ từ Customer sang customer, (2) từ vendor sang vendor, từ vendor sang customer: trường hợp này có 2 tình huống là (3) vendor cũng là customer hoặc (4) vendor khác customer.

Khi giới thiệu đến chuyển nợ từ Vendor sang vendor hay sang customer bằng T code F-44, mà 2 ông này lại không có quan hệ gì với nhau, 2 ông không control nhau trong master data. Đội support nói rằng SAP không thể làm được điều đó, vì nếu làm được điều đó thì người quản trị không kiểm soát được, enduser được phân quyền làm F-44 để clering downpayment và invoice vendor, nhưng nếu giả sử enduser chuyển nợ ông này sang ông khác thì sao? Làm sao kiểm soát được, nên make sure là SAP không cho phép và cũng không thể thực hiện được việc chuyển nợ qua F-44.

Nhưng tôi khẳng định có thể làm được điều đó vì mình đã mò ra rồi, sau khi đi vòng vòng test thử một số posting key 17, 27, 29, 39, và 34. Kết quả SAP OK có thể chuyển nợ giữa Vendor và customer, vendor và vendor, customer và customer lung tùng phèo. Híc híc, thở phào nhẹ nhõm và đội support cũng ô ô ô được à, hì…

Thế là thống nhất giữa support và tôi là sẽ tìm cách limited posting key cho các end user và không training cái clearing  này nữa.

SAP quả là tuyệt diệu.

Comments

comments

  1. Bài viết quá hay. Đối với mình nó thật bổ ích.
    Cám ơn bạn rất nhiều.

  2. Quá dài không đủ kiên nhẫn để đọc. Tuy nhiên ngay đoạn mở đầu: “Phòng TCKT hiện tại gồm 12 CBNV đảm trách cả 2 mảng FI và CO. nhưng Organize chart của phòng là 21 người mới đủ đáp ứng được yêu cầu công việc. chúng tôi đã rất khó khăn để lựa chọn ra 4 người fulltime + 01 người part time trong SAP.”. Điều này nói lên rằng khi có SAP thì đòi hỏi doanh nghiệp phải tăng thêm nguồn lực (tức là chi phí) lên rất nhiều trong khi kết quả đạt được thì rất… mơ hồ. Ở đây chỉ mới nói về FI, CO.
    Mà mình cũng không hiểu tại sao dự án lại chỉ có 3 giai đoạn: “Blue print, training, testing”…
    Không biết thế nào là hiệu quả theo tiêu đề của bài viết…

  3. daohoangquang

    bài viết này mình viết năm 2011 – trên website ERP4VN,

    các bạn copy bài của mình còn thiếu phần từ ngày 16/10/2011 đến ngày Golive 31/10/2011 và khoảng 2 tháng sau đó sau khi chạy smoothly SAP

    Các bạn quan tâm nếu cần chia sẻ nốt đoạn kết – please contact email dao_accountant@yahoo.com mình sẽ gởi

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.