Nhận tư vấn nhiều hơn

Đã gửi yêu cầu thành công

Cảm ơn bạn đã liên hệ!

ads-banner-1

Cấu trúc tổ chức hệ thống và các loại Master Data trong SAP S/4 HANA

Ngày đăng:

31/10/2024
Structure-and-master-data-in-sap-s4-hana
Cám ơn bạn đã đọc blog mình thêm một bài viết nữa. Bài viết này thuộc về chuỗi chia sẻ các thông tin liên quan đến SAP Functional mà mình muốn gửi đến cộng đồng. Chủ đề này mình sẽ nói về Cấu trúc tổ chức của doanh nghiệp và các Master Data liên quan doanh nghiệp trong hệ thống SAP S/4HANA và chúng ta sẽ đi từ những khái niệm cơ bản trước nhé.
Ok, Let's go nào!!!

 
Structure in SAP S/4HANA 

Bạn có thể nhìn hình mô tả trên, chúng ta sẽ có một số khái niệm cơ bản nhất.

Đầu tiên với khái niệm IDES và SAP Client, bạn có thể hình dung đây là một khái niệm ở mức tập đoàn, nói về hệ thống máy chủ của SAP chứa toàn bộ thông tin, nghiệp vụ liên quan ở mức cao nhất. 
Bên dưới Client sẽ tuỳ theo nhu cầu doanh nghiệp mà mình sẽ phân thành các cấu trúc có Controlling Area theo từng khu vực để quản lý. Bên dưới Controlling Area sẽ bao gồm các khái niệm về Company Code (một pháp nhân độc lập). Trong mối liên hệ giữa Controlling Area và Company Code là mối liên hệ 1-nhiều. Nghĩa là nhiều Company Code có thể phân vào 1 Controlling Area.
Việc phân theo cấu trúc này liên quan đến vấn đề quản trị, đặc biệt là vấn đề về quản lý chi phí.
1 Company Code sẽ đại diện cho 1 công ty con hoặc các chi nhánh của công ty tập đoàn mà có tư cách hạch toán độc lập. Hiểu một cách đơn giản hơn, ví dụ trong 1 tập đoàn có nhiều công ty con, mỗi công ty con ở một quốc gia. Thì mỗi công ty con như vậy sẽ có thể xây dựng thành 1 Company Code và sẽ có bộ sổ sách kế toán riêng của từng công ty con đó.
Một số trường hợp đặc biệt như ở thị trường Mỹ, mỗi tiểu bang sẽ có chính sách thuế khác nhau. Trường hợp này thì mỗi chi nhánh thuộc công ty ở từng tiểu bang khác nhau sẽ có Company Code khác nhau là bởi vì có hệ thống sổ sách kế toán tách biệt nhau.
Như vậy, thông thường khi nói về Company Code, chúng ta sẽ nói về vấn đề Kế toán. Tức là sẽ có hệ thống sổ sách kế toán, hệ thống tài khoản quản lý tất cả các giao dịch tài chính liên quan tới từng Company Code.
Nhìn vào sơ đồ trên, bạn có thể thấy ở đây có 2 Company Code là Germany và France thuộc Controlling Area là EUROPE. Thông thường khi người ta gom 2 Company Code vào cùng 1 Controlling Area như hình ví dụ sẽ có một số điểm chung về mặt sổ sách kế toán. Cụ thể như có điểm chung về hệ thống tài khoản kế toán, chuẩn mực kế toán. Và khi gom chung như vậy sẽ giúp người quản trị có thể kiểm soát các chi phí mà trong hệ thống SAP sẽ gọi là Cross Company.
Ví dụ thực tế khi chuyển hàng nội bộ giữa 2 công ty con với nhau, các chi phí phát sinh được kế toán ghi nhận vào doanh thu nội bộ hoặc là chi phí nội bộ,... Các chi phí phát sinh này mang tính chất liên công ty và sẽ được kiểm soát trong cùng 1 Controlling Area.
Kể từ đơn vị Company Code trở xuống, mình xem như các đơn vị hạch toán độc lập thì mình sẽ có các đơn vị như Plant. Ví dụ như trong hình mô tả, công ty Germany sẽ có 3 Plant là FRA, BER và HAM. Mỗi Plant này sẽ là nơi quản lý hàng hoá, vật tư. 
Thông thường đứng ở góc độ Kế toán, mỗi mã hàng sẽ được định giá theo Plant. Ví dụ một công ty có 2 Plant ở Hà Nội và TpHCM sẽ có một mã hàng được khai báo ở mỗi plant với giá khác nhau. Khi chuyển hàng từ Plant này sang Plant khác sẽ phát sinh các vấn đề về kế toán như đánh giá lại giá trị hàng tồn kho. 
Trong mỗi Plant sẽ có thêm các khái niệm về Storage Location. Với Storage Location này, thông thường được dùng để phân chia khả năng lưu trữ trong 1 Plant. Những mã hàng thuộc cùng 1 loại sẽ được đặt trong cùng 1 Storage Location để kiểm soát số lượng tồn kho trong Storage Location đó. Bạn cũng có thể hiểu Storage Location như 1 khái niệm về khu vực lưu trữ.
Tiếp theo đến với khái niệm Material Type. Thông thường định nghĩa trong SAP hay về mặt kế toán, người dùng sẽ chia các loại vật tư thành các loại cơ bản như vật tư thành phẩm (Finish Good/Products). Trong kế toán, khi ghi nhận giá trị của thành phẩm, người dùng sẽ ghi nhận trong tài khoản sổ cái riêng cho thành phẩm. Ví dụ như tài khoản 155 theo kế toán Việt Nam, đây là tài khoản dùng để phản ánh giá trị hiện có và tình hình biến động của các loại thành phẩm của doanh nghiệp.
Ngoài vật tư thành phẩm ra chúng ta có nguyên vật liệu (Raw Material), hàng hoá thương mại (Trading Goods) - những mã hàng hoá mua về và bán ra có lợi nhuận chênh lệch giữa giá mua và bán. Trong kế toán Việt Nam sẽ ghi nhận ở tài khoản 156.
Và thêm một Material Type thông dụng trong hệ thống ERP là "bán thành phẩm" (Semi Finish Goods).
Trong hình mô tả trên, còn có một số phần liên quan đến bán hàng là module SD (Sales and Distribution). 
Chúng ta có Sales Organization là một đơn vị trong doanh nghiệp phụ trách chính về mảng bán hàng. Trong hệ thống SAP, Sales Organization sẽ phải thuộc vào 1 công ty nào đó. Mỗi Sales Org sẽ có chiến lược riêng về giá, chính sách khuyến mãi,...
Bên dưới Sales Org sẽ có Division và thường được sử dụng để phân loại và quản lý sản phẩm hoặc dịch vụ trong một công ty. Ngoài Division ra thì còn các kênh phân phối nữa (Distribution Channel
Đây là một cấu trúc cơ bản liên quan đến bán hàng, ngoài ra còn có một số cấu trúc khác mà mình không thể diễn tả trong đây như cấu trúc về mua hàng. Trong mua hàng thì mình có thêm các đơn vị phụ trách mua sắm trong công ty được định nghĩa là Purchase Organization. Cùng với đó cũng sẽ có các khái niệm liên quan Purchase Group,...
Bên cạnh đó, liên quan đến Organization Unit hay Position sẽ liên quan đến nhân sự thuộc về phân hệ HCM. Khi đó phân rã các khái niệm chúng ta sẽ có khái niệm về Personal AreaPersonal SubArea
Personal Area nói về khái niệm của bộ phận nhân sự. Ví dụ một doanh nghiệp có bộ phận nhân sự ở miền Bắc và miền Nam sẽ được định nghĩa là 2 Personal Area khác nhau khi ở miền Bắc cũng có phòng kế toán, phòng kho vận, phòng kinh doanh,...và miền Nam cũng vậy.

 Source: sap.com
Với khái niệm Personal SubArea thường được định nghĩa ở cấp bậc phòng ban. 
Đôi lúc hơi nhập nhằn về khái niệm Org. Structure khi nói về toàn bộ hệ thống của tập đoàn và riêng về mảng nhân sự cũng dùng từ Org. Structure để mô tả. Nhưng về mặt cơ bản, các bạn có thể hiểu về Organizational Structure như vậy và những cấu trúc này đã được định nghĩa sẵn trong hệ thống SAP S/4HANA.
Bạn có thể xem qua bài viết: Quản trị nhân sự trong SAP S/4HANA
Với các khái niệm trên, mình hi vọng các bạn có thể nắm được các khái niệm cơ bản về môi trường Client dùng để định nghĩa hệ thống ở mức nào, các Company Code sẽ đại diện cho đơn vị gì, phụ thuộc vào Controlling Area như thế nào. Bên dưới Company CodePlant rồi đến Storage Location sẽ có ý nghĩa gì trong quản lý. 
Ngoài ra, sau này sẽ có thêm các khái niệm thường dùng như Organizational Level ở mức Plant cũng là 1 Org. Level hay Company Code cũng là một Org. Level...
Khi hiểu được các định nghĩa này, các bạn sẽ nắm được quan điểm thiết kế hệ thống của SAP, và đến lúc tìm hiểu chuyên sâu vào từng module cụ thể sẽ dễ dàng hơn. Ví dụ như hiểu rõ được thông tin của một loại chứng từ ở module này sẽ có cấu trúc như thế nào thì khi qua tiếp cận các loại chứng từ ở các module khác sẽ nhanh chóng hơn.
Phần tiếp theo chúng ta sẽ nói về Master Data.
Trong hệ thống SAP, tất cả những loại Master Data như data về khách hàng (Customer), data về hàng hoá, nhà cung cấp (Vendor), data về giá (Price),... sẽ được định nghĩa theo Org. Level.
Mình ví dụ khi build hệ thống sổ sách kế toán (tài chính) để ghi nhận các loại dữ liệu giao dịch thì được định nghĩa ở mức Org. LevelCompany CodeControlling Area. Khi nói đến Company Code thì người ta sẽ thường nói luôn đến Controlling Area nhưng Company Code là cái quan trọng nhất. Tuỳ vào mô hình kinh doanh cũng như quy định về kế toán, có nhiều trường hợp các công ty không dùng chung Chart of Accounts (COA), đặc biệt khi các yêu cầu kinh doanh và quy định riêng lẻ của từng công ty không phù hợp với việc dùng chung một bảng kế toán. Dưới đây là một số tình huống phổ biến: 
  • Ngành nghề kinh doanh khác biệt: Nếu các công ty hoạt động trong các lĩnh vực hoàn toàn khác nhau (ví dụ, một công ty làm về sản xuất, một công ty khác làm về dịch vụ), thì nhu cầu về hệ thống tài khoản sẽ khác nhau. Mỗi công ty sẽ cần các tài khoản đặc thù và không thể sử dụng chung COA. 
  • Yêu cầu tuân thủ quy định kế toán địa phương: Trong một tập đoàn đa quốc gia, các công ty con ở mỗi quốc gia phải tuân thủ quy định kế toán và pháp lý khác nhau. Ví dụ, mỗi quốc gia có thể yêu cầu các tài khoản và cách ghi nhận riêng, không đồng nhất với chuẩn mực quốc tế hoặc COA của tập đoàn mẹ. 
Các công ty sẽ thường dùng chung Chart of Accounts (COA) trong những trường hợp sau: 
  • Cùng tập đoàn hoặc tổng công ty: Khi các công ty là các pháp nhân độc lập nhưng thuộc cùng một tập đoàn, tổng công ty sẽ muốn thống nhất COA để dễ dàng tổng hợp dữ liệu tài chính cho báo cáo hợp nhất và quản lý tập trung. 
  • Hoạt động kinh doanh giống hoặc tương tự nhau: Các công ty có ngành nghề, hoạt động kinh doanh tương đồng sẽ dễ dàng sử dụng chung một COA do có các nghiệp vụ tài chính và cấu trúc tài khoản tương tự.

Khi lưu thông tin về khách hàng/nhà cung cấp sẽ có 2 loại Data 

  • Data về mặt kế toán khi giao dịch, bán hàng, mua hàng,... cần phải ghi nhận tài khoản kế toán nào được hạch toán khi khách hàng nợ tiền hay trả tiền, thông tin về hình thức thanh toán của khách hàng/nhà cung cấp (Payment Term), đơn vị tiền tệ được sử dụng,... Thông tin về mặt kế toán của khách hàng/nhà cung cấp sẽ được định nghĩa ở mức Company Code. Điều này có nghĩa là giả sử bạn có 1 khách hàng và công ty của bạn có 10 Company Code và khách hàng này làm việc với 3 Company Code của bạn thì lúc này định nghĩa data cho khách hàng này 3 lần, mỗi lần là dành cho 1 Company Code => Mỗi một Company Code khác nhau, dữ liệu về kế toán cho khách hàng này sẽ khác nhau.
  • Ngoài Data về mặt kế toán, chúng ta cũng cần lưu trữ Data về mặt bán hàng (hay mua hàng). Ví dụ khi bạn bán hàng cho một khách hàng, bạn cần có các thông tin như khách hàng muốn được giao hàng như thế nào, giao 1 lần hay nhiều lần, chọn Plant giao hàng là Plant nào,... Thì những data đó được định nghĩa ở Org. Level là Sales Area. Khi Customer này làm việc với 10 Sales Organization này thì chúng ta sẽ định nghĩa data cho Customer này cả 10 bộ Data (mỗi bộ Data cho 1 Sales Org.). Khi đó, customer lên đơn hàng đối với Sales Org. A thì sẽ có thông tin đơn hàng cho Sales Org. A, đối với Sales Org. B sẽ có thông tin đặc thù của Sales Org B.
Khi đó, chúng ta nói về Data trong SAP thì sẽ nói về Data của Org. Level.
Với 2 loại Data như vậy, chúng ta sẽ làm quen với khái niệm về Master DataTransaction Data. Có thể hiểu rằng trong hệ thống của mình có nhiều loại dữ liệu (data). Cụ thể:
  • Master Data là những thông tin ổn định hoặc ít thay đổi như là Business Partner Master Data, Item Master Data,... Đây là các dữ liệu được thiết lập ngay từ đầu và được sử dụng để tạo ra các dữ liệu giao dịch khác. Một số loại Master Data khác thường gặp trong hệ thống bao gồm: tiền tệ, đơn vị sản phẩm, ngân hàng, v.v.
  • Transaction Data là các dữ liệu được tạo ra mỗi khi người dùng thực hiện một giao dịch trên hệ thống (giao dịch là hành động có điểm bắt đầu và kết thúc của người dùng). Ví dụ về Transaction Data bao gồm thông tin đơn hàng, khách hàng, báo giá, v.v. Master Data đã có sẵn để sử dụng mà không cần người dùng can thiệp, trong khi Transaction Data chỉ được tạo ra khi người dùng thực hiện hành động trên hệ thống.
Mình biết các chủ đề bắt đầu tiếp cận hệ thống như thế này đôi lúc rất khó hiểu. Mọi người có thể đọc và để lại bình luận góp ý và mình sẽ điều chỉnh lại dần dần nhé.
Mình là Khanh Nguyễn, mình đã tốn khá nhiều thời gian để biên soạn và viết lại nội dung này. Nếu các bạn có copy vui lòng dẫn nguồn. Trân trọng cảm ơn.
Khanh Nguyễn | 01/11/2024

Để lại Lời nhắn

Đăng ký nhận bảng tin 🙌

Luôn được cập nhật với những bài viết chia sẻ mới nhất từ mình qua email.

Đăng ký ngay bây giờ, huỷ bất cứ khi nào.