"Bản đồ" là một công cụ LPgenerator mới! Giai đoạn chuẩn bị chuyển đổi báo cáo. Phát triển trò chơi máy tính

Các công ty sử dụng Excel cho mục đích báo cáo chuyển đổi sẽ nhận được khoản tiết kiệm hữu hình khi lập báo cáo tài chính theo IFRS. Nếu khối lượng giao dịch cho phép thông tin xác thực được xử lý trong bảng tính, nên sử dụng Excel

12.01.2016

Các bảng Excel, ngoài độ chính xác số học và sự rõ ràng của các quy trình chuyển đổi, còn giúp tạo ra dữ liệu để phân tích kinh tế các hoạt động tài chính dựa trên kết quả IFRS, biến mô hình báo cáo thành công cụ quản lý.

Giai đoạn chuẩn bị chuyển đổi báo cáo

Ở giai đoạn chuẩn bị, việc phân tích sự khác biệt cụ thể giữa IFRS áp dụng cho một công ty nhất định và thông lệ kế toán theo RAS được thực hiện. Cần lưu ý rằng việc bắt đầu từ các quy tắc kế toán của Nga là không phù hợp, vì trong trường hợp này sẽ khó thoát khỏi “ưu tiên hình thức hơn nội dung” - bạn nên bắt đầu bằng việc phân tích toàn bộ công ty và các hoạt động của nó theo quan điểm của IFRS.

Các tiêu chuẩn quốc tế phù hợp với từng doanh nghiệp cụ thể cần được đưa vào Chính sách kế toán theo IFRS. Ví dụ: một thực thể thương mại không được sử dụng các công cụ tài chính phức tạp hoặc các quy định của IAS 41 Nông nghiệp và một công ty tư nhân không bắt buộc phải tiết lộ thu nhập trên mỗi cổ phiếu theo IAS 33 Thu nhập trên mỗi cổ phiếu. Quy trình xây dựng chính sách kế toán không chỉ nhằm mục đích tạo ra các quy tắc kế toán và biên bản ghi nhớ theo IFRS mà còn chuẩn bị một loạt các ghi chú trực tiếp cho báo cáo IFRS, bao gồm các khía cạnh chính của chính sách kế toán cần được trình bày trong theo IAS 1 “Trình bày báo cáo tài chính”.

Dựa trên các chính sách kế toán thu được theo IFRS, cần xác định những khác biệt trong các ước tính và nguyên tắc áp dụng trong RAS, đồng thời lập danh sách và quy tắc tính toán các điều chỉnh chuyển đổi chính, cũng như danh sách thông tin thêm, cần thiết cho mục đích của IFRS, nhưng không được tính đến theo yêu cầu của pháp luật Nga.

Trong lần sử dụng đầu tiên tiêu chuẩn quốc tế Theo IFRS 1, bạn nên biết về các trường hợp ngoại lệ và sự đơn giản hóa được tiêu chuẩn cho phép và những khoản giảm nhẹ này không còn được áp dụng nữa.

Quá trình cập nhật chính sách kế toán theo IFRS, danh sách điều chỉnh và danh sách thông tin bổ sung phải liên tục vì các yêu cầu của IFRS và pháp luật Nga liên tục được cập nhật.

Biểu đồ ánh xạ tài khoản để chuyển đổi báo cáo

Ánh xạ - từ ánh xạ tiếng Anh (thư từ, cũng như chuyển đổi) - là một quy trình đăng dữ liệu trong một số hệ tọa độ, trong trường hợp của chúng tôi, chuyển đổi số dư và doanh thu được tạo theo biểu đồ tài khoản RAS thành cấu trúc của biểu đồ tài khoản theo IFRS (Bảng 1).

Bảng 1. Ví dụ về biểu đồ ánh xạ tài khoản

Đôi lời về cách vẽ sơ đồ tài khoản thực tế theo IFRS.

• Mỗi chỉ số IFRS phải có một giá trị duy nhất mã kỹ thuật số, trong trường hợp đặc biệt, là chữ và số, theo định dạng được xác định nghiêm ngặt. Tổng hợp các chỉ số hiện đại Các phiên bản Excel thậm chí có thể dựa trên các đặc điểm của văn bản, nhưng trong trường hợp này, nguy cơ biến dạng dữ liệu trong trường hợp mắc một lỗi đánh máy đơn giản sẽ tăng lên. Để giảm thiểu lỗi, các thư mục và danh sách thả xuống có mã, tên tài khoản và phân tích cũng như các công thức “SUMMIF” và “VLOOKUP” tóm tắt dữ liệu với các đặc điểm được chỉ định, cụ thể là các mã duy nhất, sẽ được sử dụng.
• Hệ thống phân cấp của biểu đồ tài khoản sẽ cho phép bạn nhóm dữ liệu không chỉ theo các phần tử mà còn theo các dòng của biểu mẫu báo cáo và ghi chú. Giả sử bài viết “Nhà cửa và vật kiến ​​trúc - Giá gốc”, ngoài mã riêng của nó, trong số các phân tích còn phải có mã dòng của báo cáo tình hình tài chính (sau đây gọi là bảng cân đối kế toán) và mã của bảng ghi chú, bảng này sẽ cho phép bạn điền vào biểu mẫu và ghi chú báo cáo dạng bảng bằng công thức Excel.
• Mỗi phần của biểu mẫu báo cáo trong biểu đồ tài khoản phải chứa các dòng trống dự phòng - điều này giúp bạn có thể điều chỉnh linh hoạt biểu đồ tài khoản mà không cần cấu hình lại công thức và cũng cho phép bạn không vi phạm nguyên tắc so sánh dữ liệu. Ví dụ: nên cung cấp không gian cho các phần mới, ví dụ: nếu công ty trước đây chưa sở hữu bất động sản đầu tư nhưng ban quản lý có kế hoạch tạo hoặc mua bất động sản để cho thuê. Trong trường hợp này, bạn chỉ cần điền vào các hàng trống và nhập mã báo cáo, Excel sẽ tự động tổng hợp các chỉ số.
• Cần lưu lại lịch sử thay đổi bản đồ (thường trên cơ sở biên bản ghi nhớ hoặc tài liệu phương pháp hành chính khác) cho biết lý do, người chịu trách nhiệm và thời điểm những thay đổi có hiệu lực. Điều này rất quan trọng để tạo ra dữ liệu có thể so sánh giữa các kỳ và để vượt qua cuộc kiểm toán.

Cần lưu ý rằng nhà phân tích càng chứa nhiều kế hoạch của Nga tài khoản, việc thực hiện các điều chỉnh ánh xạ và phân loại lại cần thiết liên quan đến các nguyên tắc tổng hợp dữ liệu khác nhau trong RAS và IFRS càng dễ dàng hơn. Do đó, nếu có thể, biểu đồ tài khoản RAS và các phân tích của nó phải càng gần với nhu cầu của IFRS càng tốt để tăng hiệu quả của quá trình chuyển đổi và giảm chi phí.

Thu thập các thông tin cần thiết để điền vào mô hình chuyển đổi.Ở giai đoạn này, dữ liệu về số dư các tài khoản trên bảng cân đối kế toán và doanh thu của các tài khoản thu nhập và chi phí trong kỳ báo cáo được thu thập, bảng cân đối kế toán ban đầu và báo cáo lãi lỗ được điền vào.

Cùng với quá trình này, các giao dịch quan trọng, kiện tụng, hợp đồng mới quan trọng và các tiết lộ bổ sung đều được xem xét. Cần xây dựng một danh sách quy định các thông tin bổ sung, cũng như chỉ định những người chịu trách nhiệm chuẩn bị các dữ liệu liên quan và phải thiết lập thời hạn.

Danh sách được trình bày trong Bảng 2 có thể được rút ngắn nếu công ty không có một số hoạt động nhất định hoặc được mở rộng đáng kể. Theo quy định, những thay đổi trong hoạt động của công ty đòi hỏi phải điều chỉnh bổ sung IFRS hiếm khi xảy ra. Do đó, việc phân tích kỹ lưỡng nhất được thực hiện trong lần làm quen đầu tiên với doanh nghiệp và chỉ sau đó những thay đổi đáng kể mới được theo dõi. Do đó, trong hầu hết các trường hợp, các công ty phải thực hiện khoảng 10 đến 20 điều chỉnh mang tính chuyển đổi, những điều chỉnh này có thể được quy định bởi các hướng dẫn liên quan và được ghi trong tài liệu “Thủ tục kế toán các điều chỉnh chuyển đổi”.

Bảng 2. Danh sách mẫu thông tin bổ sung

Mọi điều chỉnh phải được thực hiện dưới dạng tài liệu làm việc tương tự như báo cáo kế toán. Tài liệu làm việc phải có cơ sở phương pháp luận và các cơ sở thực tế trên cơ sở đó đã thực hiện một số điều chỉnh nhất định và bản thân các tính toán. Bạn cũng cần phải cài đặt thủ tục kiểm soát nhằm mục đích kiểm tra tính chính xác của các phép tính, đối chiếu dữ liệu từ các tài liệu làm việc và các mô hình chuyển đổi, cũng như tính chính xác của các bài đăng.

Giai đoạn hình thành các điều chỉnh sắp tới. Các điều chỉnh sắp tới sẽ được tạo ra khi áp dụng IFRS lần đầu tiên, cũng như trong các giao dịch liên quan đến việc mua lại các công ty mới, phải được đo lường theo giá trị hợp lý.

Để bắt đầu, bảng cân đối kế toán và các khoản mục tài khoản lãi lỗ được tập hợp lại. Đây được gọi là điều chỉnh phân loại lại. Các điều chỉnh phân loại lại chủ yếu bao gồm việc hoàn nhập hoặc hoàn nhập các khoản phải thu, phải trả và tạm ứng, phân loại lại chi phí hoãn lại, tách tài sản ngắn hạn và dài hạn và nợ phải trả, chuyển các khoản tiền gửi có kỳ hạn dưới 90 ngày thành tiền mặt, và một ghi chi tiết hơn về thu nhập và chi phí vào các hóa đơn liên quan nếu công việc tương tự chưa được thực hiện ở giai đoạn lập bản đồ (Bảng 3).

Bảng 3. Ví dụ về bảng phân loại lại

Phần điều chỉnh tiếp theo là những điều chỉnh ảnh hưởng đến số lượng các khoản mục trong bảng cân đối kế toán cũng như thu nhập và chi phí. Không nên nhầm lẫn chúng với các điều chỉnh phân loại lại vì chỉ những điều chỉnh ước tính mới ảnh hưởng đến số thuế hoãn lại theo IFRS.

Trên thực tế, số tiền điều chỉnh đáng kể nhất liên quan đến việc đo lường tài sản theo giá trị hợp lý - tài sản cố định (đặc biệt trong trường hợp công ty sở hữu tài sản cũ) và tài sản vô hình. Không thể tự mình tính toán những điều chỉnh đó vì việc này yêu cầu dữ liệu từ báo cáo kiểm tra do một thẩm định viên có trình độ thực hiện. Ví dụ, nếu không có kiến ​​thức và kinh nghiệm đặc biệt thì không thể xác định được chi phí cơ sở khách hàng, khi mua một công ty, phải được ghi nhận là tài sản vô hình theo IFRS. Chỉ sau khi nhận được dữ liệu đánh giá về giá gốc hợp lý, mức độ khấu hao và thời gian sử dụng hữu ích còn lại, sổ đăng ký tài sản cố định và tài sản vô hình theo IFRS mới được hình thành. Việc hạch toán tài sản cố định và tài sản vô hình có thể được thực hiện bằng một chương trình riêng hoặc bằng bảng tính, khi sổ đăng ký tài sản cố định được duy trì trong Excel, các khoản thu, hiện đại hóa, thanh lý đồ vật được phản ánh và khấu hao được tính theo giá gốc ghi nhận trong theo IFRS.

Cách đơn giản nhất để tính toán các điều chỉnh là so sánh dữ liệu RAS và IFRS và xác định sự khác biệt giữa chúng. Những khoản tiền này tạo thành bản sửa đổi (Bảng 4).

Bảng 4. Tính toán điều chỉnh đánh giá lại TSCĐ theo giá trị hợp lý

Ngoài việc phản ánh việc đánh giá lại, đối với tài sản cố định và tài sản vô hình, có thể cần phải tính toán lại số tiền lãi được vốn hóa vì RAS và IFRS có các cách tiếp cận khác nhau để xác định số tiền vốn hóa.

Các quy định của IAS 36 Suy giảm tài sản cũng tập trung nhiều hơn vào việc kiểm tra tài sản, nhà xưởng, thiết bị và tài sản vô hình, giá trị của chúng phải được điều chỉnh khi có bằng chứng về suy giảm giá trị.

Nếu một công ty sử dụng hợp đồng thuê tài chính trong hoạt động của mình (theo giải thích của IFRS), các sửa đổi cũng có thể ảnh hưởng đến số lượng tài sản, nhà xưởng, thiết bị và chi phí khấu hao, tương ứng với nghĩa vụ cho thuê tài chính và lãi phải thu khi sử dụng vốn vay.

Cần đặc biệt chú ý đến những điều chỉnh liên quan đến chiết khấu (ví dụ như trong trường hợp cho thuê tài chính dài hạn, khi cả nguyên giá tài sản cố định và khoản nợ theo hợp đồng thuê tài chính đều được ước tính trên cơ sở chiết khấu). IFRS yêu cầu chiết khấu mọi tài sản và nợ dài hạn:

• số tiền thu được khi trả chậm đúng thời hạn;
• số tiền dự trữ hoặc dự phòng dài hạn theo IAS 37 “Dự phòng, nợ tiềm tàng và tài sản tiềm tàng”;
• chi phí đầu tư vào công ty con khi cung cấp khoản thanh toán trả chậm cho cổ phiếu;
• thành phần nợ của trái phiếu chuyển đổi dài hạn;
• số tiền có thể thu hồi của một tài sản tài chính được tính theo giá gốc khấu hao khi được kiểm tra khả năng giảm giá, v.v.

Trong số những điều chỉnh phổ biến nhất, chúng tôi cũng có thể lưu ý:

• đối với hàng tồn kho (xóa sổ hàng tồn kho kém thanh khoản như một khoản lỗ, tạo khoản dự phòng để khấu hao hàng tồn kho, xóa bỏ sự thiếu hụt và tổn thất do hư hỏng các vật có giá trị, cũng như một số loại chi phí trả chậm nhất định);
• để giải quyết với nhân sự (điều chỉnh dự trữ cho các kỳ nghỉ, tạo quỹ dự trữ cho thù lao trong tương lai, giải quyết theo kế hoạch lương hưu);
• Điều chỉnh hạn chót (xóa doanh thu hoãn lại, trích thu nhập và chi phí bổ sung trong kỳ báo cáo không được phản ánh trong RAS do thiếu tài liệu hoặc có sự khác biệt trong cách ghi nhận thời điểm chuyển giao rủi ro và lợi ích, trong thư từ với các tài khoản thanh toán với các đối tác);
• đối với các khoản phải thu và phải trả, cũng như các khoản cho vay và đi vay (phản ánh chi phí phân bổ theo phương pháp lãi suất thực tế, điều chỉnh dự phòng cho các khoản nợ khó đòi);
• về đầu tư tài chính (ghi nhận phần lãi hoặc lỗ của các công ty liên kết, điều chỉnh giá trị của các khoản đầu tư tài chính mà theo đó giá trị thị trường hiện tại có thể được xác định, v.v.).

Sau khi tất cả các điều chỉnh ước tính đã được tạo ra, số tiền điều chỉnh thuế thu nhập hoãn lại được xác định.

Tất nhiên, không phải tất cả các điều chỉnh có thể xảy ra đều được liệt kê, vì mục tiêu là chứng minh cách hình thành nhóm các điều chỉnh sắp tới và cách thực hiện các điều chỉnh từ năm này sang năm khác (Bảng 5).

Bảng 5. Lập danh sách các điều chỉnh sắp tới

Tiếp theo, có tính đến các điều chỉnh sắp tới, một bảng cân đối kế toán, báo cáo lãi lỗ, báo cáo thay đổi vốn và báo cáo biến động sẽ được chuẩn bị. Tiền bạc theo định dạng IFRS và cũng chuẩn bị các giải trình cho báo cáo tài chính.

Những điều chỉnh cơ bản được sử dụng để chuyển vào báo cáo của các kỳ tiếp theo dưới dạng những điều chỉnh sắp tới. Có hai phương thức chuyển khoản:

• các điều chỉnh đối với các tài khoản trong bảng cân đối kế toán được xem xét tương ứng với tài khoản lợi nhuận giữ lại;
• các điều chỉnh đối với tài khoản thu nhập/chi phí được đảo ngược tương ứng với tài khoản thu nhập giữ lại.

Việc lựa chọn phương pháp chuyển khoản chỉ ảnh hưởng đến kỹ thuật tính toán các khoản điều chỉnh hiện hành cho các kỳ kế toán tiếp theo, kết quả cuối cùng sẽ giống nhau nhưng sẽ không thể thay đổi mô hình để tính toán điều chỉnh nên bạn nên xác định trước phương pháp thuận tiện nhất và tuân theo.

Giai đoạn hình thành các khoản điều chỉnh cho các kỳ báo cáo tiếp theo. Những điều chỉnh điển hình trong các kỳ báo cáo tiếp theo phải được đưa ra có tính đến những điều chỉnh sắp tới. Cơ chế tạo dữ liệu IFRS như sau: bảng excelđiền theo từng trang:

• ánh xạ số dư và doanh thu theo RAS thành số dư và doanh thu theo IFRS;
• điều chỉnh phân loại lại;
• các điều chỉnh sắp tới (không bao gồm các khoản điều chỉnh của kỳ trước);
• các khoản điều chỉnh cho kỳ hiện tại (được tính trong các tài liệu làm việc riêng biệt có tính đến các khoản điều chỉnh lũy kế đến).

Sau đó, bằng cách sử dụng công thức “SUMIF”, dữ liệu sẽ được đưa lên bảng tóm tắt (xem Bảng 6).

Bảng 6. Hình thành dữ liệu IFRS trong mô hình chuyển đổi

Dữ liệu IFRS (cột 8) có được bằng cách tổng hợp dữ liệu RAS ban đầu, phân loại lại, điều chỉnh đầu vào và hiện tại. Ở giai đoạn tiếp theo, cũng sử dụng công thức “SUMMIF”, các chỉ tiêu IFRS lập sẵn được tổng hợp trên các trang báo cáo (bảng cân đối kế toán, báo cáo lãi lỗ) theo mã dòng của các biểu mẫu báo cáo theo mã biểu mẫu báo cáo được giao (Bảng 7) . Theo cách tương tự, các mẫu ghi chú dạng bảng được điền vào, các công thức kiểm soát và đối chiếu được viết giữa bảng chuyển đổi, biểu mẫu báo cáo và ghi chú, đồng thời sự thay đổi trong thu nhập giữ lại trong kỳ được so sánh với số dư đầu kỳ và cuối kỳ của chỉ báo ( có thể có sự khác biệt về số tiền cổ tức tích lũy).

Bảng 7. Ví dụ sử dụng Hàm Excel"SUMMESLI"

Như chúng ta có thể thấy, Excel cho phép bạn tạo dữ liệu IFRS khá đơn giản và rõ ràng thông qua chuyển đổi. Trong thực tế, các phương pháp khác để điền vào bảng biến đổi cũng được sử dụng, chẳng hạn như bộ cờ cổ điển. Tuy nhiên, nếu điều chỉnh nhiều thì file thu được sẽ cồng kềnh và rủi ro sẽ tăng lên. lỗi kỹ thuật Hơn nữa, việc phân tích các sửa đổi tích lũy qua nhiều thời kỳ trở nên khó khăn. Dù sử dụng mô hình chuyển đổi nào, đều có những khuyến nghị chung để làm việc với Excel: việc lưu trữ dữ liệu phải được tổ chức trên nền tảng đáng tin cậy và được bảo vệ khỏi truy cập trái phép may chủ, tạo tự động bản sao lưu các tệp làm việc chính và tự động lưu trong quá trình làm việc, lưu trữ thường xuyên cả dữ liệu chính và mô hình cuối cùng, theo dõi các thay đổi đối với tệp và duy trì tệp trạng thái tóm tắt (danh sách kiểm tra) chứa thông tin về các giai đoạn chuyển đổi cần thiết và mức độ hoàn thành các quy trình đã thiết lập.

Trong phần trước, chúng ta đã xem xét các loại mối quan hệ (một-một, một-nhiều, nhiều-nhiều), cũng như một lớp Book và lớp ánh xạ BookMap của nó. Trong phần thứ hai, chúng ta sẽ cập nhật lớp Sách, tạo các lớp còn lại và kết nối giữa chúng, như được mô tả trong chương trước trong Sơ đồ cơ sở dữ liệu nằm phía trên tiêu đề phụ 1.3.1 Mối quan hệ.

Mã lớp và ánh xạ (Có nhận xét)

Sách học

Lớp công khai Sách ( //Mã định danh duy nhất public virtual int Id ( get; set; ) // Tiêu đề chuỗi ảo công khai Tên ( get; set; ) // Mô tả chuỗi ảo công khai Mô tả ( get; set; ) // Xếp hạng của Thế giới của Fiction public virtual int MfRaiting ( get; set; ) // Số trang public virtual int PageNumber ( get; set; ) // Liên kết tới hình ảnh public virtual string Image (get; set; ) // Ngày đến của sách (filter bởi các mục mới!) Ngày ảo công khai Ngày thu nhập ( get; set; ) // Thể loại (Nhiều-nhiều) // Tại sao ISet mà không phải IList? Chỉ có thể chọn một bộ sưu tập (IList) bằng cách tìm nạp THAM GIA, nếu bạn cần thêm hơn một bộ sưu tập để tìm nạp THAM GIA, thì tốt hơn là chuyển đổi chúng thành bộ sưu tập ISet ảo công khai ISet Thể loại ( get; set; ) //Sê-ri (Nhiều-một) Sê-ri ảo công khai Sê-ri ( get; set; ) // Ý kiến ​​​​và ý kiến ​​​​riêng tư (Một-một) khác Tâm trí _mind; Tâm trí ảo công khai Tâm trí ( get ( return _mind ?? (_mind = new Mind()); ) set ( _mind = value; ) ) //Tác giả (Nhiều-nhiều) ISet ảo công khai Tác giả ( get; set; ) //Khởi tạo trước để không xảy ra ngoại lệ null. public Book() ( //Bộ không có thứ tự (một bảng không thể có hai hàng giống hệt nhau, nếu không nó sẽ chọn một hàng và bỏ qua hàng kia) Genres = new HashSet (); Tác giả = HashSet mới (); ) ) //Lớp ánh xạ Sách lớp công khai BookMap: ClassMap ( public BookMap() ( Id(x => x.Id); Map(x => x.Name); Map(x => x.Description); Map(x => x.MfRaiting); Map(x = > x.PageNumber); Map(x => x.Image); Map(x => x.IncomeDate); //Mối quan hệ nhiều-nhiều HasManyToMany(x => x.Genres) //Quy tắc xếp tầng Tất cả - Khi đối tượng được lưu, cập nhật hoặc xóa, tất cả các đối tượng phụ thuộc đều được kiểm tra và //created/updated/add.Cascade.SaveUpdate() //Tên của bảng trung gian PHẢI giống với lớp Genre! .Table("Book_Genre "); HasManyToMany(x = > x.Authors) .Cascade.SaveUpdate() .Table("Book_Author"); //Mối quan hệ nhiều-một Tham chiếu(x => x.Series); //Một-một- một mối quan hệ. Lớp chính. HasOne(x => x.Mind).Cascade.All().Constrain(); ) )

Lớp công khai Tác giả ( public virtual int Id ( get; set; ) //Tên-Họ chuỗi ảo công khai Tên ( get; set; ) //Tiểu sử chuỗi ảo công khai Tiểu sử ( get; set; ) // Sách ISet ảo công khai Sách ( get; set; ) //Khởi tạo Tác giả public Author() ( Books=new HashSet (); ) ) // Tác giả Ánh xạ lớp công khai AuthorMap: ClassMap ( public AuthorMap() ( Id(x => x.Id); Map(x => x.Name); Map(x => x.Biography); //Mối quan hệ nhiều-nhiều HasManyToMany(x => x .Books) //Quy tắc phân tầng Tất cả - Khi một đối tượng được lưu, cập nhật hoặc xóa, tất cả các đối tượng phụ thuộc sẽ được kiểm tra và tạo/cập nhật/thêm.Cascade.All() // Chủ sở hữu của bộ sưu tập là đầu bên kia của mối quan hệ (Sách) và sẽ được lưu trước . .Inverse() //Tên của bảng trung gian PHẢI giống với lớp Sách! .Table("Book_Author"); ) )

Thể loại lớp

Public class Genre ( public virtual int Id ( get; set; ) //Tên thể loại public virtual string Tên (get; set; ) //Tên tiếng Anh của thể loại public virtual string EngName (get; set; ) //Books ISet ảo công khai Sách ( get; set; ) //Khởi tạo sách công khai Thể loại() ( Books=new HashSet (); ) ) // Ánh xạ thể loại public class GenreMap: ClassMap ( public GenreMap() ( Id(x => x.Id); Map(x => x.Name); Map(x => x.EngName); //Mối quan hệ nhiều-nhiều HasManyToMany(x => x .Books) //Quy tắc phân tầng Tất cả - Khi một đối tượng được lưu, cập nhật hoặc xóa, tất cả các đối tượng phụ thuộc sẽ được kiểm tra và tạo/cập nhật/thêm.Cascade.All() // Chủ sở hữu của bộ sưu tập là đầu bên kia của mối quan hệ (Sách) và sẽ được lưu trước . .Inverse() //Tên của bảng trung gian PHẢI giống với lớp Sách! .Table("Book_Genre"); ) )

Ý kiến ​​của lớp:

Public class Mind ( public virtual int Id ( get; set; ) // Ý kiến ​​của tôi public virtual string MyMind ( get; set; ) // Ý kiến ​​của Fantlab public virtual string MindFantLab ( get; set; ) // Book public virtual Book Book ( get; set; ) ) //Mapping Mind public class MindMap:ClassMap ( public MindMap() ( Id(x => x.Id); Map(x => x.MyMind); Map(x => x.MindFantLab); //Mối quan hệ một đối một HasOne(x => x .Sách ); ) )

Chu kỳ lớp học (Sê-ri):

Sê-ri lớp công khai ( Id int ảo công khai ( get; set; ) Tên chuỗi ảo công khai ( get; set; ) // Tôi đã tạo IList, không phải ISet, vì ngoài Sách, Sê-ri không được liên kết với bất kỳ thứ gì khác, mặc dù bạn có thể làm và ISet IList ảo công khai Sách ( get; set; ) //Khởi tạo sách. public Series() ( Sách = Danh sách mới (); ) ) lớp công khai SeriesMap: ClassMap ( public SeriesMap() ( Id(x => x.Id); Map(x => x.Name); //Mối quan hệ một-nhiều HasMany(x => x.Books) ////Chủ sở hữu của bộ sưu tập ... đầu kia của mối quan hệ (Sách) và nó sẽ được lưu trước. .Inverse() ) )

Một chút giải thích
ISet ảo công khai Thể loại(get;set;)
ISet ảo công khai Tác giả ( get; set; )

Tại sao tôi đặt , và không phải IList quen thuộc với nhiều người ? Nếu chúng ta sử dụng IList thay vì ISet và thử chạy dự án, chúng ta sẽ không nhận thấy nhiều sự khác biệt (Bảng và lớp sẽ được tạo). Nhưng khi chúng ta thêm các bảng Thể loại và Tác giả vào lớp Book LeftJoin cùng lúc, đồng thời chúng ta cũng cố gắng hiển thị các bản ghi không lặp lại từ bảng Sách (Distinct Book.Id) vào một dạng xem (View), Nhibernate sẽ đưa ra một ngoại lệ và một lỗi.
Không thể lấy nhiều túi cùng một lúc.
Trong những trường hợp như vậy, chúng tôi sử dụng ISet, đặc biệt vì các bộ được thiết kế cho việc này (chúng bỏ qua các bản ghi trùng lặp).

Mối quan hệ nhiều-nhiều.

NHibernate có khái niệm về bảng "chính". Mặc dù mối quan hệ nhiều-nhiều giữa bảng Book và Author là tương đương (Một tác giả có thể có nhiều sách, một sách có thể có nhiều tác giả) nhưng Nhibernate yêu cầu người lập trình chỉ định bảng được lưu trữ thứ hai (có phương thức nghịch đảo). ()), nghĩa là, trước tiên một bản ghi sẽ được tạo/cập nhật/xóa trong bảng Sách và sau đó chỉ trong bảng Tác giả.
Cascade.All có nghĩa là thực hiện các thao tác xếp tầng khi lưu-cập nhật và xóa. Nghĩa là, khi một đối tượng được lưu, cập nhật hoặc xóa, tất cả các đối tượng phụ thuộc đều được kiểm tra và tạo/cập nhật/thêm (Ps. Có thể viết thay vì Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Method.Table("Book_Author"); tạo một bảng “trung gian” “Book_Author” trong cơ sở dữ liệu.

Mối quan hệ nhiều-một, một-nhiều.

Phương thức The.Constrained() cho NHibernate biết rằng một bản ghi từ bảng Sách phải khớp với một bản ghi từ bảng Mind (id của bảng Mind phải bằng id của bảng Book)

Nếu bây giờ bạn chạy dự án và xem cơ sở dữ liệu Bibilioteca, các bảng mới với các kết nối đã được hình thành sẽ xuất hiện.

Tiếp theo, điền dữ liệu vào các bảng đã tạo...
Để thực hiện việc này, chúng tôi sẽ tạo một ứng dụng thử nghiệm để lưu dữ liệu trong cơ sở dữ liệu, cập nhật và xóa nó, thay đổi HomeController như sau (chúng tôi nhận xét về các phần không cần thiết của mã):
public ActionResult Index() ( sử dụng (ISession session = NHibernateHelper.OpenSession()) ( sử dụng (ITransaction giao dịch = session.BeginTransaction()) ( //Tạo, thêm var createBook = new Book(); createBook.Name = "Metro2033" ; createBook.Description = "Chủ nghĩa thần bí hậu tận thế"; createBook.Authors.Add(tác giả mới ( Name = "Glukhovsky" )); createBook.Genres.Add(Thể loại mới ( Name = "Chủ nghĩa thần bí hậu tận thế" )); createBook .Series = Series mới ( Name = "Metro" ); createBook.Mind = new Mind ( MyMind = "Chủ nghĩa thần bí hậu tận thế" ); session.SaveOrUpdate(createBook); //Update (By ID) //var series = session .Lấy (1); //var updateBook = session.Get (1); //updateBook.Name = "Metro2034"; //updateBook.Description = "Dystopia"; //updateBook.Authors.ElementAt(0).Name = "Glukhovsky"; //updateBook.Genres.ElementAt(0).Name = "Dystopia"; //updateBook.Series = loạt; //updateBook.Mind.MyMind = "11111"; //session.SaveOrUpdate(updateBook); //Xóa (Theo ID) //var deleteBook = session.Get (1); //session.Delete(deleteBook); giao dịch.Commit(); ) Thể loại Thể loạiAl = null; Tác giả tác giảAl = null; Chuỗi dãyAl = null; Tâm tríAl = null; var books = session.QueryOver () //Left Join with table Genres .JoinAlias(p => p.Genres, () => .JoinAlias(p => p.Authors, () => AuthorAl, JoinType.LeftOuterJoin) .JoinAlias(p => p .Series, () => seriesAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Mind, () => mindAl, JoinType.LeftOuterJoin) //Xóa số id trùng lặp của bảng Sách. .TransformUsing(Transformers.DistinctRootEntity ). List(); return View(sách); ) )

Một chút giải thích

1. var books = session.QueryOver () Chọn * Từ Sách;
2. .JoinAlias(p => p.Thể loại, () => thể loạiAl, JoinType.LeftOuterJoin)- tương tự như thực thi tập lệnh SQL:
   CHỌN *TỪ Sách
   bên trong THAM GIA Book_Genre ON book.id = Book_Genre.Book_id
   TRÁI THAM GIA Thể loại TRÊN Book_Genre.Genre_id = Genre.id
3. .TransformUsing(Transformers.DistinctRootEntity)- Tương tự như thực thi tập lệnh SQL: CHỌN Sách.Id riêng biệt..., (xóa các bản ghi trùng lặp có cùng id)

Các loại hiệp hội
.JoinAlias(p => p.Thể loại, () => thể loạiAl, JoinType.LeftOuterJoin)

1. LeftOuterJoin - chọn tất cả các bản ghi từ bảng bên trái ( Sách), rồi nối thêm các bản ghi bảng bên phải vào chúng ( Thể loại). Nếu không tìm thấy mục tương ứng trong bảng bên phải, hãy hiển thị nó dưới dạng Null
2. RightOuterJoin ngược lại với LEFT JOIN - nó chọn tất cả các bản ghi từ bảng bên phải ( Thể loại), rồi nối thêm các bản ghi bảng bên trái vào chúng ( Sách)
3. InnerJoin - chỉ chọn những bản ghi từ các bảng bên trái ( Sách) có mục nhập tương ứng từ bảng bên phải ( Thể loại), rồi nối chúng với các bản ghi từ bảng bên phải

Hãy thay đổi cách biểu diễn như sau:

Chế độ xem chỉ mục

@model IEnumerable @( Bố cục = null; )

@Html.ActionLink("Tạo mới", "Tạo")

@foreach (var item trong Model) ( @(string strSeries = item.Series != null ? item.Series.Name: null;) }

@Html.DisplayNameFor(model => model.Name)	@Html.DisplayNameFor(model => model.Mind)	@Html.DisplayNameFor(model => model.Series)	@Html.DisplayNameFor(model => model.Authors)	@Html.DisplayNameFor(model => model.Genres)	Hoạt động
@Html.DisplayFor(modelItem => item.Name)	@Html.DisplayFor(modelItem => item.Mind.MyMind)	@Html.DisplayFor(modelItem => strSeries)	@foreach (var tác giả trong item.Authors) ( string strAuthor = Author != null ? Author.Name: null; @Html.DisplayFor(modelItem => strAuthor) }	@foreach (var thể loại trong item.Genres) ( chuỗi strGenre = thể loại!= null ? thể loại.Name: null; @Html.DisplayFor(modelItem => strGenre) }	@Html.ActionLink("Chỉnh sửa", "Chỉnh sửa", mới ( id = item.Id )) | @Html.ActionLink("Chi tiết", "Chi tiết", mới ( id = item.Id )) | @Html.ActionLink("Xóa", "Xóa", mới ( id = item.Id ))

Sau khi kiểm tra từng hoạt động một, chúng ta sẽ nhận thấy rằng:

• Trong các thao tác Tạo và Cập nhật, tất cả dữ liệu liên kết với bảng Sách đều được cập nhật (xóa Cascade="save-update" hoặc Cascade="all" và dữ liệu liên quan sẽ không được lưu)
• Khi xóa, dữ liệu bị xóa khỏi các bảng Book, Mind, Book_Author nhưng dữ liệu còn lại không bị xóa vì có Cascade="save-update"

Ánh xạ cho các lớp có tính kế thừa.
Làm cách nào để ánh xạ các lớp có tính kế thừa? Giả sử chúng ta có ví dụ này:
//Lớp hình dạng hai chiều public class TwoDShape ( //Width public virtual int width ( get; set; ) // Chiều cao public virtual int Height ( get; set; ) ) // Class Triangle public class Triangle: TwoDShape ( / /Số nhận dạng public virtual int Id ( get; set; ) //Loại chuỗi ảo public kiểu tam giác Kiểu ( get; set; ) )

Về nguyên tắc, không có gì phức tạp trong việc ánh xạ này; chúng ta sẽ chỉ tạo một ánh xạ cho lớp dẫn xuất, tức là bảng Tam giác.
// Ánh xạ tam giác lớp công khai TriangleMap: ClassMap ( public TriangleMap() ( Id(x => x.Id); Map(x => x.Style); Map(x => x.Height); Map(x => x.Width); ) )
Sau khi khởi chạy ứng dụng, bảng (trống) sau sẽ xuất hiện trong cơ sở dữ liệu Biblioteca

thẻ:

• asp.net mvc 4
• nhibernate
• máy chủ sql

Thêm thẻ

Các lớp được thay thế phải khai báo một cột khóa chính trong bảng cơ sở dữ liệu. Hầu hết các lớp cũng phải khai báo các thuộc tính kiểu JavaBeans của riêng chúng, bao gồm cả mã định danh thực thể duy nhất. Yếu tố trong tệp ánh xạ, họ sẽ xác định ánh xạ của trường duy nhất này tới cột trong bảng, cột này đóng vai trò là khóa chính.

(5)

(1)	name (tùy chọn): Tên của thuộc tính định danh.
(2)	type (tùy chọn): Tên xác định loại Hibernate của thuộc tính.
(3)	cột (tùy chọn - tên thuộc tính mặc định): Tên của cột khóa chính.
(4)	giá trị chưa được lưu (tùy chọn - mặc định là null): Giá trị thuộc tính định danh cho biết phiên bản đó là mới (theo thuật ngữ lưu trữ liên tục). Phân biệt phiên bản này với các phiên bản chuyển tuyến đã được tải hoặc lưu trong phiên bản trước.
(5)	truy cập (tùy chọn - mặc định là thuộc tính): Đây là chiến lược mà Hibernate sẽ sử dụng để truy cập vào một thuộc tính nhất định của một đối tượng.

Nếu thuộc tính tên không được chỉ định, lớp đó được coi là không có thuộc tính định danh.

Thuộc tính giá trị chưa được lưu là quan trọng! Nếu thuộc tính id mặc định của lớp bạn không phải là null, bạn phải đặt thuộc tính "giá trị chưa được lưu" thành giá trị thích hợp.

Có một thông báo thay thế để truy cập dữ liệu cũ bằng các phím tổng hợp. Chúng tôi đặc biệt không khuyến khích việc sử dụng khóa tổng hợp trong các trường hợp khác.

5.1.4.1. máy phát điện

Yêu cầu phần tử con "a định nghĩa một lớp Java được sử dụng để tạo ra các mã định danh duy nhất cho các thể hiện của các lớp không ổn định. Nếu cần, phần tử Để truyền các tham số khởi tạo hoặc cấu hình cho một phiên bản trình tạo.

bảng uid_table cột tiếp theo_hi_value_column

Tất cả các trình tạo đều triển khai giao diện net.sf.hibernate.id.IdentifierGenerator. Đó là một giao diện rất đơn giản; nhiều ứng dụng có thể sử dụng cách triển khai trình tạo tùy chỉnh của riêng chúng. Mặc dù vậy, Hibernate bao gồm nhiều trình tạo tích hợp sẵn. Dưới đây là tên viết tắt (nhãn) của các trình tạo tích hợp:

Tăng

tạo các mã định danh loại dài, ngắn hoặc int chỉ duy nhất khi không có quy trình nào khác đang thêm dữ liệu vào cùng một bảng. Không sử dụng trong một cụm.

danh tính

Hỗ trợ các cột nhận dạng trong DB2, MySQL, MS SQL Server, Sybase và HypersonicSQL. Kiểu định danh trả về là dài, ngắn hoặc int.

sự liên tiếp

Sử dụng trình tự trong DB2, PostgreSQL, Oracle, SAP DB, McKoi hoặc trình tạo trong Interbase. Kiểu định danh trả về là dài, ngắn hoặc int.

xin chào

Sử dụng thuật toán hi/lo để tạo hiệu quả các mã định danh thuộc loại long, short hoặc int, yêu cầu tên bảng và cột (theo mặc định là hibernate_unique_key và next_hi, tương ứng) làm nguồn của các giá trị hi. Thuật toán hi/lo tạo ra các mã định danh duy nhất cho từng cơ sở dữ liệu. Không sử dụng trình tạo này cho các kết nối JTA hoặc kết nối tùy chỉnh.

tiếp theo

sử dụng thuật toán hi/lo để tạo các mã định danh loại dài, ngắn hoặc int, sử dụng chuỗi cơ sở dữ liệu.

uuid.hex

Sử dụng thuật toán UUID 128 bit để tạo số nhận dạng chuỗi duy nhất trong mạng (sử dụng địa chỉ IP). UUID là một chuỗi 32 ký tự chứa biểu diễn thập lục phân của số.

uuid.string

sử dụng cùng một thuật toán UUID, nhưng chuỗi khi sử dụng trình tạo này bao gồm 16 (một số) ký tự ANSII. Không sử dụng với PostgreSQL.

tự nhiên

chọn danh tính, trình tự hoặc hilo, tùy thuộc vào khả năng của cơ sở dữ liệu đang được sử dụng.

giao

cung cấp cho ứng dụng khả năng đặt mã định danh đối tượng một cách độc lập trước khi gọi phương thức save().

nước ngoài

mã định danh của đối tượng liên quan khác được sử dụng. Thường được sử dụng trong các giao dịch với liên kết bằng khóa chính.

5.1.4.2. Thuật toán Hi/Lo

Trình tạo hilo và seqhilo cung cấp hai cách triển khai thay thế của thuật toán hi/lo, cách tiếp cận ưa thích để tạo mã định danh. Lần triển khai đầu tiên yêu cầu một bảng "đặc biệt" trong cơ sở dữ liệu để lưu trữ giá trị "hi" tiếp theo. Cách triển khai thứ hai sử dụng trình tự (kiểu Oracle) trong cơ sở dữ liệu hỗ trợ chúng.

hi_value giá trị tiếp theo 100 hi_value 100

Thật không may, bạn không thể sử dụng hilo khi cung cấp Kết nối của mình cho Hibernate và bạn cũng không thể sử dụng nó trong cấu hình trong đó Hiberante sử dụng nguồn dữ liệu máy chủ ứng dụng do JTA quản lý. Hiberante phải có khả năng nhận được giá trị "hi" trong giao dịch mới. Cách tiếp cận tiêu chuẩn trong EJB, là sử dụng một đậu không trạng thái phiên để triển khai thuật toán hi/lo.

5.1.4.3. Thuật toán UUID

Đừng cố sử dụng uuid.string trong PostgreSQL.

5.1.4.4. Trình tự và cột nhận dạng

Bạn có thể sử dụng trình tạo khóa nhận dạng cho các cơ sở dữ liệu hỗ trợ các cột thụt lề (DB2, MySQL, Sybase, MS SQL). Đối với cơ sở dữ liệu hỗ trợ trình tự, bạn có thể sử dụng kiểu trình tự để tạo khóa. Cả hai chiến lược này đều yêu cầu hai truy vấn SQLđể chèn một đối tượng mới vào cơ sở dữ liệu.

uid_sequence

Để phát triển các ứng dụng đa nền tảng, hãy sử dụng chiến lược gốc. Nó sẽ sử dụng các chiến lược nhận dạng, trình tự và hilo tùy thuộc vào khả năng của cơ sở dữ liệu mà nó được kết nối. khoảnh khắc này thời gian Hibernate đang chạy.

5.1.4.5. ID được xác định

Nếu bạn muốn ứng dụng tự gán ID, bạn có thể sử dụng trình tạo được chỉ định. Trình tạo đặc biệt này sử dụng ID do ứng dụng đặt. Để thực hiện việc này, ứng dụng sẽ đặt mã định danh thành thuộc tính tương ứng của đối tượng. Hãy hết sức cẩn thận khi sử dụng tính năng này để đặt khóa (trong hầu hết các trường hợp, quyết định này báo hiệu thiết kế ứng dụng kém).

Do tính chất vốn có của nó, các thực thể sử dụng trình tạo này không thể được lưu thông qua phương thức Session.saveOrUpdate(). Thay vào đó, bạn phải thông báo rõ ràng cho Hibernate biết liệu đối tượng nên được tạo hay cập nhật bằng cách gọi các phương thức đối tượng Session thích hợp: save() hoặc update().

5.1.5. id tổng hợp

......

Đối với các bảng có khóa tổng hợp, bạn có thể hiển thị nhiều thuộc tính lớp dưới dạng thuộc tính nhận dạng đối tượng. Yếu tố chấp nhận ánh xạ thuộc tính bằng cách sử dụng các phần tử con Và .

Lớp liên tục của bạn phải ghi đè các phương thức bằng() và hashCode() để triển khai tính tương đương của mã định danh tổng hợp. Nó cũng phải triển khai giao diện Serializable.

Thật không may, khả năng chỉ định các mã định danh tổng hợp ngụ ý rằng đối tượng cố định chính là mã định danh. Không có khả năng xử lý thuận tiện hơn thông qua chính đối tượng đó. Bạn phải tự tạo một thực thể lớp liên tục và đặt thuộc tính nhận dạng của nó trước khi tải() trạng thái liên tục được liên kết với mã định danh tổng hợp đó. Chúng tôi sẽ mô tả một cách thích hợp hơn, trong đó các mã định danh tổng hợp được triển khai dưới dạng một lớp riêng biệt, trong Phần 7.4, “Thành phần dưới dạng Mã định danh tổng hợp”. Các thuộc tính được mô tả dưới đây chỉ có thể áp dụng cho phương pháp thay thế:

tên (tùy chọn): Thuộc tính loại thành phần có chứa mã định danh tổng hợp (xem phần tiếp theo).

class (tùy chọn, theo mặc định, loại thuộc tính được xác định thông qua sự phản chiếu): thành phần của lớp này được sử dụng làm định danh tổng hợp (xem phần tiếp theo).

giá trị chưa được lưu (tùy chọn, mặc định là không có): Nếu được đặt thành bất kỳ, điều này cho biết rằng các thực thể chuyển tiếp được coi là mới.

5.1.6. người phân biệt đối xử

Yếu tố cần thiết cho tính bền vững đa hình bằng cách sử dụng chiến lược ánh xạ phân cấp theo bảng cho mỗi lớp. Phần tử này khai báo một cột phân biệt đối xử, được sử dụng để xác định xem một mục trong bảng có tương ứng với một lớp cụ thể trong hệ thống phân cấp hay không. Bộ phân biệt đối xử có thể là một trong các loại sau: chuỗi, ký tự, số nguyên, byte, ngắn, boolean, Yes_no, true_false.

Các giá trị cột discriminator tương ứng cho mỗi lớp được chỉ định trong thuộc tính discriminator-value cho các phần tử Và .

Thuộc tính lực chỉ hữu ích nếu bảng chứa các bản ghi có thêm các giá trị phân biệt đối xử không xuất hiện trong lớp cố định. Thông thường thuộc tính này không được sử dụng.

5.1.7. phiên bản (tùy chọn)

Yếu tố phản ánh rằng bảng chứa các bản ghi được gắn thẻ phiên bản. Điều này đặc biệt hữu ích nếu bạn định sử dụng giao dịch dài(xem bên dưới).

(1)	cột (tùy chọn, mặc định là tên thuộc tính): tên của cột lưu trữ số phiên bản.
(2)	name: Tên của thuộc tính lớp liên tục.
(3)	type (tùy chọn, mặc định là số nguyên): Loại thuộc tính phiên bản.
(4)
(5)	giá trị chưa được lưu (tùy chọn, mặc định là không xác định): Giá trị thuộc tính phiên bản cho biết thực thể chưa được lưu (chưa được lưu). Đừng nhầm lẫn các thực thể chưa được lưu với các thực thể chuyển tiếp đã được lưu hoặc tải trong phiên trước đó. (không xác định cho biết giá trị định danh sẽ được sử dụng.)

Số phiên bản có thể thuộc loại dài, số nguyên, ngắn, dấu thời gian hoặc lịch.

5.1.8. dấu thời gian (tùy chọn)

Yếu tố chỉ ra rằng bảng chứa các bản ghi được đánh dấu bằng dấu thời gian. Phần tử này hoạt động như một sự thay thế cho các điểm đánh dấu phiên bản. Dấu thời gian theo định nghĩa là cách triển khai khóa lạc quan kém an toàn hơn. Tuy nhiên, đôi khi một ứng dụng sử dụng dấu thời gian cho các mục đích khác

(1)	cột (tùy chọn, mặc định là tên thuộc tính): Tên của cột chứa dấu thời gian.
(2)	name: Tên kiểu JavaBeans của thuộc tính Date hoặc Timestamp của lớp cố định.
(3)	truy cập (tùy chọn, mặc định là thuộc tính): Chiến lược mà Hibernate nên sử dụng để truy cập giá trị của thuộc tính.
(4)	giá trị chưa được lưu (tùy chọn - mặc định là null): Giá trị thuộc tính thời gian cho biết thực thể chưa được lưu (chưa được lưu). Đừng nhầm lẫn các thực thể chưa được lưu với các thực thể chuyển tiếp đã được lưu hoặc tải trong phiên trước đó. (không xác định cho biết giá trị định danh sẽ được sử dụng.)

Lưu ý: phần tử tương đương với phần tử .

5.1.9. tài sản

Yếu tố Khai báo một thuộc tính kiểu JavaBeans bền vững của một lớp.

(1)	name: Tên của thuộc tính, bắt đầu bằng chữ cái viết thường.
(2)	cột (tùy chọn, tên thuộc tính được thay thế theo mặc định): tên của cột tương ứng trong bảng cơ sở dữ liệu.
(3)	type (tùy chọn): Tên của loại Hibernate.
(4)	cập nhật, chèn (tùy chọn, mặc định là đúng): chỉ ra rằng cột tương ứng phải được đưa vào các câu lệnh SQL UPDATE và/hoặc INSERT. Việc đặt cả hai thuộc tính thành false cho phép đặt giá trị của thuộc tính đó từ một thuộc tính khác được hiển thị trong cùng một cột/cột, thông qua trình kích hoạt hoặc bởi một ứng dụng khác.
(5)	công thức (tùy chọn): Một biểu thức SQL tính toán giá trị của thuộc tính. Các trường được tính toán không được ánh xạ tới cột trong bảng cơ sở dữ liệu.
(6)	truy cập (tùy chọn, mặc định là thuộc tính): Chiến lược mà Hibernate nên sử dụng để truy cập giá trị của thuộc tính.

giá trị của thuộc tính loại có thể là một trong những giá trị sau:

Tên của loại cơ sở Hibernate (ví dụ: số nguyên, chuỗi, ký tự, ngày tháng, dấu thời gian, float, nhị phân, tuần tự hóa, đối tượng, blob).

Tên lớp Java (ví dụ: int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).

Tên của một lớp bắt nguồn từ PersistentEnum (ví dụ: eg.Color).

Tên của lớp Java sẽ được tuần tự hóa.

Tên của lớp tùy chỉnh (ví dụ: com.illflow.type.MyCustomType).

Nếu bạn không chỉ định giá trị cho thuộc tính loại, Hibernate sẽ sử dụng sự phản ánh trên thuộc tính được chỉ định để đoán loại Hibernate thích hợp. Hibernate sẽ cố gắng xác định tên lớp của thuộc tính được trả về bằng phương thức get() bằng cách sử dụng quy tắc 2, 3, 4 theo thứ tự đó. Tuy nhiên, điều này không phải lúc nào cũng đủ. Trong một số trường hợp, bạn vẫn cần chỉ định thuộc tính type. (Ví dụ: để phân biệt giữa Hibernate.DATE và Hibernate.TIMESTAMP hoặc để chỉ định loại tùy chỉnh.)

Thuộc tính access cho phép bạn kiểm soát cách Hibernate truy cập một trường trong thời gian chạy. Theo mặc định, Hibernate gọi các phương thức get/set để truy cập một trường. Nếu bạn chỉ định access="field" thì Hibernate sẽ bỏ qua các phương thức get/set và truy cập trực tiếp vào trường bằng cách sử dụng sự phản chiếu. Bạn có thể chỉ định chiến lược truy cập của riêng mình bằng cách chỉ định một lớp triển khai giao diện net.sf.hibernate.property.PropertyAccessor.

5.1.10. nhiều-một

Một mối quan hệ bình thường với một lớp liên tục khác được khai báo bằng phần tử nhiều-một. Về mặt quan hệ, nó là sự kết hợp nhiều-một. Nó thực sự chỉ là một tham chiếu đến một đối tượng.

(1)	name: Tên tài sản.
(2)	cột (tùy chọn): Tên cột.
(3)	class (tùy chọn - theo mặc định, loại trường được xác định thông qua sự phản chiếu): Tên của lớp được liên kết.
(4)	tầng (tùy chọn): Chỉ định thao tác nào sẽ xếp tầng từ đối tượng cha đến đối tượng liên quan.
(5)
(6)	cập nhật, chèn (tùy chọn - đúng theo mặc định) xác định rằng các cột được hiển thị sẽ được bao gồm trong các truy vấn SQL UPDATE và/hoặc INSERT. Việc đặt cả hai thuộc tính thành false cho phép đặt giá trị của thuộc tính đó từ một thuộc tính khác được hiển thị trong cùng một cột/cột, thông qua trình kích hoạt hoặc bởi một ứng dụng khác.
(7)	property-ref: (tùy chọn) Tên thuộc tính chính của lớp được liên kết. Thuộc tính này sẽ được sử dụng để ràng buộc. Nếu không được chỉ định, khóa chính của lớp liên kết sẽ được sử dụng.
(8)	truy cập (tùy chọn - mặc định là thuộc tính): Chiến lược mà Hibernate sử dụng để truy cập giá trị của một trường nhất định.

Thuộc tính tầng có thể nhận các giá trị sau: tất cả, lưu-cập nhật, xóa, không có. Việc đặt một giá trị khác không sẽ đòi hỏi một số thao tác nhất định trên đối tượng (con) được liên kết. Xem "Vòng đời đối tượng" bên dưới.

Thuộc tính external-join có thể nhận ba giá trị sau:

tự động (mặc định) truy xuất các đối tượng được liên kết bằng cách sử dụng phép nối ngoài nếu lớp được liên kết không có proxy.

true Luôn truy xuất các đối tượng liên quan bằng cách sử dụng phép nối ngoài.

false Không bao giờ truy xuất các đối tượng liên quan bằng cách sử dụng phép nối ngoài.

Một khai báo liên kết nhiều-một điển hình trông như thế này

Thuộc tính property-ref chỉ được sử dụng để liên kết với dữ liệu kế thừa khi khóa ngoại tham chiếu đến một giá trị duy nhất của bảng được liên kết không phải là khóa chính. Đây là một quyết định quan hệ nguy hiểm. Ví dụ: có thể lớp Sản phẩm có số thứ tự duy nhất không phải là khóa chính. (Thuộc tính duy nhất kiểm soát việc tạo DDL của Hibernate. Việc tạo DDL được thực hiện bằng tiện ích SchemaExport.)

Ánh xạ cho OrderItem có thể sử dụng:

Trên thực tế, làm điều này rất không được khuyến khích.

5.1.11. một đối một

Liên kết một-một với một lớp liên tục khác có thể được khai báo bằng phần tử một-một.

(1)	name: Tên tài sản.
(2)	lớp (tùy chọn - theo mặc định được xác định bởi sự phản chiếu dựa trên loại trường): Tên của lớp được liên kết.
(3)	tầng (tùy chọn) chỉ định thao tác nào sẽ được xếp tầng từ đối tượng cha sang đối tượng liên quan.
(4)	bị ràng buộc (tùy chọn) chỉ định rằng khóa ngoại tham chiếu đến một bảng của lớp liên kết bị ràng buộc bởi khóa chính của bảng đó. Tùy chọn này ảnh hưởng đến thứ tự thực hiện các thao tác xếp tầng save() và delete() (và cũng được sử dụng bởi công cụ xuất lược đồ).
(5)	kết nối bên ngoài (tùy chọn - mặc định là tự động): Cho phép truy xuất các đối tượng được liên kết bằng cách sử dụng kết nối bên ngoài nếu tùy chọn tệp cấu hình hibernate.use_outer_join được bật.
(6)	property-ref: (tùy chọn) Tên thuộc tính của lớp liên kết được bao gồm trong khóa chính của lớp này. Nếu không được chỉ định, khóa chính của lớp liên kết sẽ được sử dụng.
(7)	truy cập (tùy chọn, mặc định là thuộc tính): Chiến lược mà Hibernate nên sử dụng để truy cập vào trường này.

Có hai loại liên kết một-một:

mối quan hệ khóa chính

mối quan hệ sử dụng khóa ngoại duy nhất

Để tổ chức liên kết bằng khóa chính, không cần thêm cột; Nếu hai bản ghi có liên quan với nhau bằng một liên kết như vậy, điều đó có nghĩa là hai bản ghi trong hai bảng có cùng giá trị khóa chính. Do đó, nếu bạn muốn liên kết hai đối tượng để chúng có liên quan với nhau bằng khóa chính thì bạn phải đảm bảo rằng ID của chúng được đặt thành cùng một giá trị!

Đối với liên kết khóa chính, hãy thêm ánh xạ sau cho các lớp Nhân viên và Người tương ứng.

Bây giờ chúng ta cần đảm bảo rằng khóa chính của các bản ghi liên quan trong các bảng là giống hệt nhau. Chúng tôi sử dụng một trình tạo nước ngoài Hibernate đặc biệt:

người lao động ...

Phiên bản cố định của lớp Person được gán cùng một giá trị khóa chính được gán cho phiên bản của lớp Nhân viên được tham chiếu bởi thuộc tính nhân viên của lớp Người.

Để thay thế cho việc mô tả mối quan hệ một-một từ Nhân viên với Người thông qua khóa ngoại duy nhất, bạn có thể sử dụng ký hiệu sau:

Sự liên kết này có thể được thực hiện hai chiều bằng cách thêm biểu thức sau vào ánh xạ của lớp Person:

5.1.12. thành phần, thành phần động

Yếu tố ánh xạ các trường của một đối tượng lồng nhau vào các cột trong bảng của lớp cha. Các thành phần có thể lần lượt xác định các thuộc tính, thành phần hoặc bộ sưu tập của riêng chúng. Xem "Thành phần" bên dưới.

(5) ........

(1)	name: Tên của thuộc tính (tham chiếu đến đối tượng thành phần).
(2)	lớp (tùy chọn - theo mặc định, loại thành phần được xác định bằng cách sử dụng sự phản chiếu): Tên của lớp thành phần.
(3)	chèn: Nếu được đặt thành true, các trường được hiển thị của thành phần sẽ tham gia vào truy vấn SQL INSERT.
(4)	cập nhật: Nếu được đặt thành true, các trường được hiển thị của thành phần sẽ tham gia vào các truy vấn CẬP NHẬT SQL.
(5)	access (tùy chọn - mặc định là thuộc tính): Chiến lược mà Hibernate nên sử dụng khi truy cập Bean này thông qua đối tượng cha của nó.

Thẻ lồng nhau Ánh xạ các trường thành phần vào các cột trong bảng.

Yếu tố cho phép phần tử lồng nhau Nó hiển thị thuộc tính thành phần dưới dạng tham chiếu ngược cho đối tượng cha.

Yếu tố cho phép bạn sử dụng Bản đồ làm thành phần trong đó tên trường tương ứng với các khóa của Bản đồ.

5.1.13. lớp con

Cuối cùng, tính bền vững đa hình yêu cầu mọi lớp con của lớp cơ sở phải được khai báo. Đối với chiến lược hiển thị (được khuyến nghị), hệ thống phân cấp bảng cho mỗi lớp sử dụng phần tử .

.....

Mỗi lớp con phải khai báo các trường và lớp con liên tục của riêng nó. Được phép thừa kế tài sản Và từ lớp cơ sở. Mỗi lớp con trong hệ thống phân cấp phải xác định một giá trị phân biệt đối xử duy nhất. Nếu giá trị này không được chỉ định thì tên lớp đầy đủ sẽ được sử dụng làm dấu phân biệt đối xử.

5.1.14. lớp con đã tham gia

Ngoài ra, một lớp con có các đối tượng được lưu trữ trong một bảng riêng biệt (chiến lược ánh xạ bảng cho mỗi lớp con) được khai báo bằng phần tử .

.....

Chiến lược hiển thị này không yêu cầu phải chỉ định cột phân biệt đối xử. Tuy nhiên, mỗi lớp con phải khai báo một cột trong bảng chứa mã định danh để phần tử hiển thị . Ánh xạ được đưa ra ở đầu phần có thể được viết lại như sau:

Trạng thái liên tục bao gồm các tham chiếu đến các thực thể và thể hiện khác của các loại giá trị. Giá trị là nguyên thủy, bộ sưu tập, thành phần và các đối tượng bất biến khác. Không giống như các thực thể, các phiên bản loại giá trị (đặc biệt là các bộ sưu tập và thành phần) được duy trì và xóa khi có sẵn. Vì các đối tượng loại giá trị (và nguyên thủy) được lưu trữ và xóa cùng với thực thể chứa chúng nên chúng không thể có phiên bản độc lập. Các giá trị cũng không có danh tính độc lập và do đó không thể chia sẻ giữa hai thực thể hoặc bộ sưu tập.

Tất cả các loại trong Hibernate, ngoại trừ các bộ sưu tập, đều hỗ trợ ngữ nghĩa con trỏ null.

Cho đến thời điểm này, chúng ta đã sử dụng thuật ngữ "lớp liên tục" để chỉ các thực thể. Chúng tôi sẽ tiếp tục làm điều này. Nói đúng ra, không phải tất cả các lớp do người dùng định nghĩa có trạng thái liên tục đều là thực thể. Ví dụ: một thành phần là một lớp do người dùng định nghĩa với ngữ nghĩa kiểu giá trị (các thành phần là một phần của các thực thể chứa chúng và được coi là các trường của các thực thể đó).

5.2.2. Các loại giá trị cơ bản

Các loại cơ bản có thể được chia đại khái như sau

số nguyên, dài, ngắn, float, double, ký tự, byte, boolean, Yes_no, true_false

Ánh xạ của các kiểu Java nguyên thủy hoặc các lớp trình bao bọc tới các kiểu cột bảng SQL tương ứng (phụ thuộc vào nhà cung cấp). boolean, Yes_no và true_false là các ký hiệu thay thế cho các kiểu Java boolean hoặc java.lang.Boolean.

sợi dây

Ánh xạ loại java.lang.String thành VARCHAR (hoặc Oracle VARCHAR2).

ngày, giờ, dấu thời gian

Ánh xạ loại java.util.Date và các lớp con của nó thành các loại SQL DATE, TIME và TIMESTAMP (hoặc tương đương).

lịch, lịch_ngày

Ánh xạ loại java.util.Calendar sang các loại SQL TIMESTAMP và DATE (hoặc tương đương).

lớn_thập phân

Kiểu ánh xạ java.math.BigDecimal thành NUMERIC (hoặc Oracle NUMBER).

địa phương, múi giờ, tiền tệ

Ánh xạ các loại java.util.Locale, java.util.TimeZone và java.util.Currency thành VARCHAR (hoặc Oracle VARCHAR2). Các phiên bản Ngôn ngữ và Tiền tệ được ánh xạ tới mã ISO của chúng. Các phiên bản TimeZone được ánh xạ tới số nhận dạng (ID) của chúng.

lớp học

Kiểu ánh xạ java.lang.Class tới VARCHAR (hoặc Oracle VARCHAR2). Lớp được hiển thị dưới dạng tên đầy đủ của nó.

nhị phân

Ánh xạ các mảng byte tới kiểu SQL nhị phân tương ứng.

chữ

Hiển thị các chuỗi Java dài trong SQL CLOB hoặc TEXT.

có thể tuần tự hóa

Ánh xạ các kiểu Java có thể tuần tự hóa thành các kiểu SQL nhị phân tương ứng. Bạn cũng có thể biểu thị loại có thể tuần tự hóa Hibernate là tên của lớp hoặc giao diện Java có thể tuần tự hóa, không phải là loại cơ sở và không triển khai giao diện PersistentEnum.

cục, cục

Ánh xạ kiểu JDBC của các lớp java.sql.Clob và java.sql.Blob. Những loại này có thể gây bất tiện cho một số ứng dụng vì các đối tượng blob và clob không thể được sử dụng bên ngoài các giao dịch. (Ngoài ra, driver không hỗ trợ đầy đủ và thống nhất các loại này.)

Mã định danh duy nhất cho các thực thể và bộ sưu tập có thể thuộc bất kỳ loại cơ bản nào ngoại trừ nhị phân, blob và clob. (Giá trị nhận dạng tổng hợp cũng được cho phép, xem bên dưới.)

Các loại giá trị cơ bản được mô tả bằng các hằng số được khai báo trong net.sf.hibernate.Hibernate. Ví dụ: Hibernate.STRING đại diện cho kiểu chuỗi.

5.2.3. Các loại enum liên tục

Kiểu liệt kê là một thành ngữ Java cơ bản khi một lớp có số lượng phiên bản bất biến (nhỏ) không đổi (lưu ý của người dịch trong Java 5, điều này đã được giới thiệu ở cấp độ ngôn ngữ, trong các phiên bản trước, một mẫu đặc biệt đã được sử dụng cho việc này). Bạn có thể tạo các kiểu enum liên tục bằng cách triển khai giao diện net.sf.hibernate.PersistentEnum và xác định các hoạt động toInt() và fromInt():

Gói ví dụ; nhập net.sf.hibernate.PersistentEnum; lớp công khai Màu thực hiện PersistentEnum ( mã int cuối cùng riêng tư; Màu riêng tư (mã int) ( this.code = code; ) cuối cùng tĩnh công khai Màu TABBY = Màu mới (0); cuối cùng tĩnh công khai Màu GINGER = Màu mới (1); công khai static Final Color BLACK = new Color(2); public int toInt() ( return code; ) public static Color fromInt(int code) ( switch (code) ( case 0: return TABBY; case 1: return GINGER; case 2: trả về ĐEN; mặc định: ném ngoại lệ RuntimeException mới ("Mã màu không xác định"); ) ) )

Tên của kiểu Hibernate chỉ đơn giản là tên của lớp được liệt kê, trong trường hợp này là Color.

5.2.4. Các loại giá trị tùy chỉnh

Các nhà phát triển có thể dễ dàng tạo ra các loại giá trị của riêng mình. Ví dụ: bạn có thể muốn lưu trữ các thuộc tính loại java.lang.BigInteger vào các cột loại VARCHAR. Hibernate không cung cấp loại tích hợp sẵn cho việc này. Nhưng việc xác định loại tùy chỉnh không bị giới hạn ở việc ánh xạ các thuộc tính (hoặc phần tử bộ sưu tập) vào một cột trong bảng. Vì vậy, ví dụ: bạn có thể có thuộc tính getName()/setName() thuộc loại java.lang.String được lưu trữ trong các cột FIRST_NAME, INITIAL, SURNAME.

Để triển khai một loại tùy chỉnh, hãy triển khai một trong các giao diện net.sf.hibernate.UserType hoặc net.sf.hibernate.CompositeUserType và khai báo thuộc tính bằng cách sử dụng tên lớp đủ điều kiện của việc triển khai loại của bạn. Xem lại net.sf.hibernate.test.DoubleStringType để biết các khả năng sẵn có.

Lưu ý: sử dụng thẻ để hiển thị các thuộc tính trong nhiều cột.

Mặc dù sự phong phú của các kiểu tích hợp và hỗ trợ thành phần của Hibernate có nghĩa là bạn hiếm khi cần sử dụng các kiểu tùy chỉnh, nhưng vẫn nên sử dụng chúng làm các lớp (không phải thực thể) cho các kiểu thường được sử dụng trong ứng dụng của bạn. Ví dụ: lớp MonetoryAmount là một ứng cử viên sáng giá cho CompositeUserType, mặc dù nó có thể được hiển thị dưới dạng một thành phần. Động lực chính là sự trừu tượng. Với các loại tùy chỉnh, tài liệu ánh xạ của bạn sẽ linh hoạt hơn trước những thay đổi có thể xảy ra trong tương lai nếu bạn thay đổi cách trình bày loại tiền tệ.

5.2.5. Bất kỳ loại hiển thị

Có một loại khác để hiển thị thuộc tính. Phần tử hiển thị khai báo một liên kết đa hình cho các lớp từ nhiều bảng. Kiểu hiển thị này luôn yêu cầu nhiều hơn một cột. Cột đầu tiên chứa loại thực thể liên quan. Các cột còn lại chứa mã định danh. Không thể xác định khóa ngoại cho một loại liên kết nhất định, do đó ánh xạ này thường không được sử dụng cho các liên kết đa hình. Bạn chỉ nên sử dụng ánh xạ này trong các trường hợp đặc biệt (ví dụ: ghi lại các loại dữ liệu khác nhau, truy cập dữ liệu phiên của người dùng).

Thuộc tính meta-type cho phép ứng dụng chỉ định một loại tùy chỉnh ánh xạ các giá trị cột cơ sở dữ liệu tới các lớp liên tục có thuộc tính định danh thuộc loại được xác định bởi id-type. Nếu loại meta trả về các thực thể java.lang.Class thì không yêu cầu gì khác. Trong các trường hợp khác, khi đó là kiểu cơ sở như chuỗi hoặc ký tự, bạn phải ánh xạ các giá trị vào các lớp.

..... .....

(1)	name: Tên tài sản.
(2)	id-type: Loại định danh.
(3)	meta-type (tùy chọn - mặc định là lớp): một loại ánh xạ java.lang.Class vào một cột cơ sở dữ liệu duy nhất hoặc cách khác là một loại được phép ánh xạ một bộ phân biệt đối xử.
(4)	tầng (tùy chọn - mặc định là không có): Loại hoạt động xếp tầng.
(5)	truy cập (tùy chọn - mặc định là thuộc tính): Chiến lược mà Hibernate nên sử dụng để truy cập giá trị của thuộc tính.

Thuộc tính đối tượng cũ, có vị trí riêng trong Hibernate 1.2, vẫn được hỗ trợ nhưng không còn được dùng nữa.

5.3. Mã định danh SQL trong dấu ngoặc kép

Bạn có thể buộc Hibernate trích dẫn mã định danh trong câu lệnh SQL. Hibernate sẽ tuân theo các quy tắc trích dẫn theo phương ngữ SQL được chỉ định (thường là dấu ngoặc kép, nhưng dấu ngoặc đơn cho SQL Server và dấu ngoặc kép cho MySQL).

...

5.4. Tập tin hiển thị riêng lẻ

Bạn có thể khai báo ánh xạ lớp con và lớp con đã nối trong các tài liệu riêng biệt, ngay bên trong phần tử ánh xạ ngủ đông. Điều này cho phép mở rộng hệ thống phân cấp lớp bằng cách thêm một tệp ánh xạ mới. Với cách tiếp cận này, bạn phải chỉ định một thuộc tính mở rộng trong ánh xạ lớp con có chứa tên của siêu lớp được ánh xạ trước. Việc sử dụng tính năng này làm cho thứ tự liệt kê các tài liệu bản đồ trở nên quan trọng.

Bản đồ cảng- đây là sự chuyển hướng của dữ liệu đã nhận theo cách mà dữ liệu nhận được trên một số cổng của máy tính này sẽ tự động được chuyển hướng đến một số cổng khác của máy tính khác.

Trên thực tế, việc thực hiện về mặt kỹ thuật dễ dàng hơn nhiều so với việc giải thích nguyên tắc đó. Điều này có thể được so sánh với tia nắng: nếu bạn hướng một chùm ánh sáng vào gương, nó sẽ “tự động” phản xạ và chiếu sáng một vật thể. Hơn nữa, nếu bạn chiếu sáng một người mà người này không biết rằng tia sáng được phản chiếu từ gương, anh ta sẽ nghĩ rằng ánh sáng đến từ nơi đặt gương. Ở đây cũng vậy: tất cả dữ liệu bạn truyền sẽ được truyền mà không có bất kỳ biến dạng nào sang máy tính khác, máy tính này có thể được đặt ở bất kỳ đâu.

Công nghệ này hơi giống với máy chủ proxy nhưng đơn giản hơn và kém linh hoạt hơn nhiều.

Sơ đồ này gần giống như khi sử dụng proxy (bạn có thể nói rằng ánh xạ cổng tương tự như proxy - nhưng điều này cũng giống như nói “ông nội giống như cháu trai” - trên thực tế, proxy tương tự như ánh xạ cổng ):

Máy tính của bạn >>> máy tính có ánh xạ cổng >>> máy chủ từ xa.

Tại sao bạn cần lập bản đồ cổng?

1. Nếu tổ chức của bạn sử dụng proxy công ty thì bằng cách định cấu hình ánh xạ cổng trên proxy đó tới máy chủ thư bên ngoài (mail.ru), bạn có thể sử dụng bất kì chương trình thư từ bên trong mạng công ty - và bạn không cần phải cài đặt/cấu hình bất kỳ chương trình bổ sung nào!
2. Theo cách tương tự như chương trình email, bạn có thể định cấu hình hầu hết mọi chương trình khác! Giá như nó hỗ trợ TCP/IP.

Tất nhiên, đây chỉ là những cách chính để sử dụng bản đồ cổng. Có nhiều loại hoạt động khác mà nó cũng sẽ rất rất hữu ích.

Lợi ích của việc lập bản đồ cổng

1. Hệ thống này rất đơn giản và có nhiều chương trình trên Internet cho phép bạn thực hiện chức năng này;
2. Vì dữ liệu được truyền đi 100% mà không có bất kỳ biến dạng nào nên bạn được đảm bảo ẩn danh 100%;
3. Nếu sử dụng hệ thống này, bạn không cần bất kỳ "bộ soxifier" nào - vì không cần khởi tạo kết nối bổ sung nên việc kết nối với trình ánh xạ cổng tương đương với việc kết nối với máy tính từ xa.

Nhược điểm của bản đồ cổng

1. Hệ thống này không linh hoạt. Không giống như proxy, nơi bạn có thể kết nối với nhiều trang web thông qua một proxy, bạn có thể kết nối thông qua một ánh xạ cổng chỉ một máy chủ.
2. Đối với mỗi ánh xạ cổng mới, bạn cần thay đổi cài đặt trên máy chủ nơi chức năng này được triển khai - tính năng này không có sẵn trên máy khách.
3. Trên mạng KHÔNG trình ánh xạ cổng miễn phí (do những hạn chế cực độ của chúng - ánh xạ một cổng chỉ cho phép truy cập vào một máy chủ), vì vậy nếu bạn muốn ẩn danh thực sự trên máy tính của mình, bạn cần phải có một máy chủ ở đâu đó để cài đặt chương trình ánh xạ cổng - và lúc này địa chỉ của máy chủ này sẽ “tỏa sáng” trong nhật ký website.

Cách làm việc với ánh xạ cổng

Xin lưu ý rằng sơ đồ làm việc với ánh xạ cổng gần giống như khi làm việc với proxy, thậm chí còn đơn giản hơn. Ánh xạ cổng là bí danh (tên bổ sung) cho máy tính được cấu hình.

Giả sử rằng việc ánh xạ cổng đã được thực hiện:

192.168.1.255:1234 => www.mail.ru:80 (cổng 80 là cổng máy chủ web)

Sau đó, để mở trang web mail.ru, bạn có thể sử dụng 2 phương pháp - mở trang web trong cửa sổ trình duyệt:

1. http://www.mail.ru
2. http://192.168.1.255:1234/
   (trong trường hợp này, hãy chắc chắn viết http://)

Tôi muốn lưu ý: nếu bạn cần phải sử dụng ánh xạ cổng thì bạn chỉ nên sử dụng địa chỉ thứ hai. Nghĩa là, nếu bạn không thể kết nối với mail.ru, thì bạn chỉ nên sử dụng địa chỉ nội bộ (http://192.168.1.255:1234/).

Ánh xạ cổng trên máy tính cục bộ

Trong trường hợp khi bạn thực hiện ánh xạ cổng trên máy tính của mình, bạn thường chỉ ra:

1. cổng cục bộ - cổng cục bộ trên máy tính mà bạn sẽ cần kết nối để sử dụng ánh xạ cổng. Con số này có thể là bất cứ thứ gì (từ 1 đến 65535), tốt nhất là lớn hơn 1000;
2. máy chủ từ xa - máy tính đó (máy chủ), trên đó chỉ định ánh xạ cổng. Ví dụ: đây có thể là máy chủ thư pop.mail.ru;
3. cổng từ xa - cổng máy tính, mà Kết nối sẽ xảy ra thông qua ánh xạ cổng. Để nhận thư (POP3), đây thường là cổng 110, để gửi thư (SMTP) - cổng 25, cho máy chủ web (www...) - đây thường là cổng 80.

Vì vậy, trong trường hợp này bạn cần (bằng cách thiết lập ánh xạ cổng) để kết nối Không tới mail.ru (và những thứ tương tự) và chỉ định máy tính của bạn làm máy chủ:

127.0.0.1:cổng địa phương

trong đó localport là số cổng được chỉ định khi định cấu hình ánh xạ cổng. Ví dụ: đây có thể là cổng 1234.

Tức là, nếu bạn đã lập bản đồ cổng trên một trang web thì bạn cần viết: http://127.0.0.1:1234/

Nếu bạn đang thiết lập thư thì hãy chỉ định làm máy chủ thư 127.0.0.1 - cả để nhận và gửi thư. Và đừng quên tìm cài đặt số cổng (POP3 và SMTP) trong ứng dụng email của bạn và thay đổi chúng theo cài đặt của bạn trong ánh xạ cổng!

Việc ra quyết định nhanh chóng và chất lượng cao của ban quản lý doanh nghiệp phụ thuộc vào hệ thống kế toán quản trị được xây dựng tốt trong công ty. Kế toán quản trịỞ đây, theo thông lệ được chấp nhận chung, việc sử dụng thuật ngữ này có nghĩa là việc sử dụng các nguyên tắc quản lý tài chính kế toán để giải quyết các vấn đề trong các lĩnh vực sau của doanh nghiệp:

• xây dựng và thực hiện chiến lược kinh doanh;
• thực hiện lập kế hoạch và kiểm soát;
• sử dụng hiệu quả các nguồn lực;
• tăng hiệu quả hoạt động;
• bảo quản tài sản hữu hình và vô hình;
• quản lý quy trình kinh doanh của công ty và nội bộ công ty

Trong mọi trường hợp, việc truy cập thông tin kế toán được thực hiện bằng nhiều loại báo cáo khác nhau.

Vì việc thu thập và lưu trữ dữ liệu về hoạt động kinh tế của doanh nghiệp là một quá trình khá tốn kém và tốn kém nên việc sử dụng hiệu quả thông tin này trở thành một nhiệm vụ quan trọng và là lợi thế cạnh tranh. Khối lượng thông tin thu thập được ban lãnh đạo công ty xác định là giải pháp dung hòa giữa yêu cầu của nhà nước và cơ quan quản lý về công bố thông tin và khối lượng thông tin tối đa (tài chính, công nghệ, thống kê) phát sinh trong quá trình hoạt động kinh doanh của doanh nghiệp. .

Cách hiệu quả nhất để sử dụng thông tin được tạo ra trong quá trình hoạt động là tạo kho dữ liệu (datewarehouse), trên cơ sở đó, sử dụng công nghệ OLAP, bất kỳ người quản lý doanh nghiệp nào cũng có thể tạo báo cáo để phân tích dữ liệu trong bối cảnh phân tích mà mình cần và cung cấp cho mình thông tin để ra quyết định.

Tuy nhiên, hiện tại, tùy chọn phổ biến nhất vẫn là tạo ra một hệ thống thông tin trong đó dữ liệu được tích lũy và theo quy định, có một trình tạo báo cáo tùy chỉnh bổ sung cho các báo cáo tiêu chuẩn do nhà phát triển hệ thống cung cấp.

Thông thường, các nhà phát triển phần mềm cung cấp cho người dùng các biểu mẫu báo cáo bên ngoài (dành cho cơ quan quản lý) (kế toán và thuế) được cập nhật thường xuyên và quảng cáo khả năng tạo bất kỳ loại báo cáo quản lý nào theo yêu cầu của doanh nghiệp. Tuy nhiên, báo cáo được tạo ra không nhất thiết phải đúng định dạng.
Doanh nghiệp chỉ còn lại vấn đề tạo (điền) báo cáo một cách chính xác.

Việc doanh nghiệp phải lập báo cáo theo Tiêu chuẩn Quốc tế chỉ có thể làm tình hình trở nên trầm trọng hơn.

Điểm mấu chốt trong báo cáo trong mọi trường hợp là cần tạo sự kết nối giữa thông tin xác thực trong hệ thống thông tin và các trường tương ứng trong biểu mẫu báo cáo.

Có thể có các tùy chọn sau để tổ chức mối quan hệ:

• Dưới dạng bảng mô tả mối quan hệ hoặc tương ứng giữa các trường báo cáo và dữ liệu trong hệ thống (tiếp theo là viết thuật toán tạo báo cáo tự động).
• Bằng cách chọn thủ công các thông tin cần thiết (hoàn toàn không có khả năng tự động hóa báo cáo).
• Phiên bản hỗn hợp yêu cầu sự hiện diện của các bảng tương quan cũng như giải mã và điều chỉnh thủ công khi tạo báo cáo.

Phương án đầu tiên để tổ chức mối quan hệ của hệ thống thông tin kế toán với các biểu mẫu báo cáo (thông qua các bảng mô tả mối quan hệ) được gọi là “ lập bản đồ".

Ánh xạ (theo nghĩa rộng) là sự chuyển đổi dữ liệu từ dạng này sang dạng khác. Đối với kế toán, ánh xạ là việc tổng hợp một bảng đối chiếu các tài khoản kế toán từ các biểu đồ tài khoản khác nhau, ví dụ: biểu đồ tài khoản của Nga và biểu đồ tài khoản GAAP (IFRS) (hoặc biểu đồ tài khoản kế toán quản trị).

Ví dụ 1. Phiên bản hỗn hợp của tổ chức truyền thông.

Hầu hết các công ty đều chuẩn bị báo cáo, chẳng hạn như theo IFRS, thông qua chuyển đổi. Phương pháp này dựa trên cách tiếp cận trong đó thông tin được tạo ra theo tiêu chuẩn của Nga sẽ được phân tích và điều chỉnh để tuân thủ IFRS.

Báo cáo được chuyển đổi trong ít nhất bốn giai đoạn bằng cách sử dụng bảng ánh xạ và điều chỉnh thủ công.

Giai đoạn 1. Chuyển đổi cơ cấu của bảng cân đối kế toán và báo cáo kết quả hoạt động kinh doanh. Kết quả là việc tập hợp và tập hợp các khoản mục riêng lẻ trong báo cáo tài chính để chuẩn bị cơ sở dữ liệu cho các mục điều chỉnh tiếp theo. Đồng thời, bảng ánh xạ chứa các chỉ số báo cáo tài chính theo RAS và phản ánh của chúng trong báo cáo giữa niên độ theo IFRS.

giai đoạn 2. Thực hiện các mục điều chỉnh nhằm loại bỏ sự khác biệt về chất giữa báo cáo của Nga và báo cáo theo IFRS. Được thực hiện thủ công bởi chuyên gia chuyển đổi.

giai đoạn thứ 3. Lập báo cáo theo IFRS dựa trên bảng cân đối kế toán, báo cáo lãi lỗ được chuyển đổi và các hình thức khác. Bảng ánh xạ bao gồm các số liệu báo cáo tạm thời theo IFRS và mô tả các điều chỉnh do chuyên gia chuyển đổi thực hiện.

giai đoạn thứ 4. Chuẩn bị phần mô tả của báo cáo.

Bảng 1. Minh họa mối tương quan giữa biểu đồ tài khoản của Nga với biểu đồ tài khoản GAAP (trích xuất)

Phòng đầu tư (thuế)

Đầu tư. Khởi hành (Được khấu trừ)

Phòng đánh giá

Phòng định giá (khấu trừ)

Phòng nghiên cứu (thuế)

Phòng nghiên cứu (khấu trừ)

Thuế VAT bán hàng VAT

VAT - dịch vụ

Nhược điểm dịch vụ VAT

Tổng doanh thu

Tổng doanh thu/doanh thu

Chi phí bán hàng

Đầu tư. Khởi hành (Được khấu trừ)

Các khoản thuế khác phải trả (TsP)

Thu thuế khác

Biên độ giao dịch (chiết khấu, cape)

Biên độ giao dịch (chiết khấu, bổ sung)

Chiết khấu của nhà cung cấp để hoàn trả chi phí vận chuyển

Chiết khấu của nhà cung cấp khi bù đắp chi phí vận chuyển

Bán và thanh lý tài sản cố định

Xử lý tài sản cố định

Bán tài sản khác

Thanh lý tài sản khác

Sản xuất chính

Sản xuất cơ bản

Sản xuất phụ trợ

Sản phẩm bổ sung

Chi phí sản xuất chung

Chi phí sản xuất chung

Phòng Tiếp thị (thuế)

Khởi hành thị trường (Được khấu trừ)

Phòng Tiếp thị (không chịu thuế)

Khởi hành thị trường (không được khấu trừ)

	Bán hàng – hoạt động chính		Bán hàng/doanh thu – hoạt động chính
	Chi phí bán hàng
	Lợi nhuận gộp		Mạng lưới bán hàng
	Chi phí chung, bán hàng và quản lý		Bán, cho chung và chi phí hành chính

Các bảng ánh xạ cũng được sử dụng trong việc tạo báo cáo quản lý doanh nghiệp (thường là ở các công ty cổ phần và công ty có chi nhánh).

Cơ sở để thiết lập ánh xạ là phân nhóm dữ liệu kế toán theo một cách nhất định (theo tiêu chuẩn công ty).

Nói một cách đơn giản, khi tạo dòng báo cáo doanh nghiệp, chúng tôi chỉ ra chính xác doanh thu (hoặc số dư tài khoản (tài khoản phụ)) và hệ thống kế toán tự động nên sử dụng thứ tự nào để tạo dòng này.

Lập bản đồ là các quy tắc bạn đã đặt ra, theo đó các báo cáo bạn cần sẽ được tạo ra. Nguyên tắc kỹ thuật tạo đường ánh xạ đối với tất cả các biểu mẫu báo cáo đều giống nhau, chỉ khác nhau ở nội dung.

Về vấn đề này, cần lưu ý rằng việc lập bản đồ phải được cấu hình bởi các chuyên gia có trình độ và quan trọng là theo một phương pháp luận thống nhất. Quá trình lập bản đồ đòi hỏi khá nhiều thời gian.

Cơ sở của kế toán quản trị (cũng như kế toán) là: sơ đồ tài khoản, các khoản mục ngân sách và các sổ sách tham khảo phân tích khác nhau.

Tuy nhiên, sơ đồ quản lý tài khoản khác biệt đáng kể so với sơ đồ tài khoản tiêu chuẩn được sử dụng để hạch toán kế toán, vì một số tài khoản trong sơ đồ quản lý tài khoản (sau đây gọi là MCA) có thể có các phân tích chi tiết hơn và phần còn lại có thể có những phân tích toàn diện hơn (tất cả phụ thuộc vào từng doanh nghiệp cụ thể). Cấu trúc của sách tham khảo phân tích cũng khác, vì báo cáo quản trị yêu cầu trình bày thông tin kế toán trong một bối cảnh hoàn toàn khác so với báo cáo kế toán.

Tất nhiên, trong thực tế, các chỉ số liên kết ( lập bản đồ) quản lý, kế toán thuế và kế toán (tài chính) gây ra rất nhiều vấn đề.
Chúng ta hãy nhìn vào một số trong số họ.

1. Thiếu sự phân tích trong sơ đồ hoạt động của các tài khoản (sau đây gọi tắt là WCA) của công ty.

Điều này cũng dễ hiểu, bởi những doanh nghiệp được thành lập trong một ngày không phải lúc nào cũng có chiến lược dài hạn và lợi ích của cổ đông không phải lúc nào cũng được tôn trọng. Ngày nay, văn hóa kinh doanh đã thay đổi. Các cổ đông, bao gồm cả nhà nước, ngày càng quan tâm đến việc các nhà quản lý ở các cấp quản lý doanh nghiệp một cách thành thạo và khéo léo như thế nào.
Giải pháp cho vấn đề này là mở rộng, bổ sung hệ thống máy tính tiền hiện có của công ty và tích lũy dần thông tin về các tài khoản mới được giới thiệu (tài khoản phụ).

Hiểu được các phương pháp chính để xây dựng Sơ đồ tài khoản, cũng như ba thành phần (tài chính, thuế, quản lý) của hệ thống kế toán thống nhất trong công ty, sẽ xác định trước nhu cầu làm nổi bật ba thành phần cơ bản trong cách tiếp cận có hệ thống đối với hệ thống kế toán tài chính của tổ chức thương mại, cụ thể là:

1. kế toán tài chính);
2. Thuế;
3. quản lý.

Những giải thích có thể có về các thành phần tài chính, thuế và quản lý của cách tiếp cận có hệ thống đối với RPS được trình bày dưới đây.

Thành phần tài chính (kế toán). Việc sử dụng RPS phải đảm bảo khả năng tạo ra tất cả (không có ngoại lệ) các chỉ số kế toán và phân tích thu được của báo cáo tài chính bên ngoài và các thuyết minh trong bối cảnh các tài khoản Sổ cái tổng hợp kể từ ngày báo cáo. Khối tài khoản kế toán của RPS liên quan đến việc lập báo cáo kế toán bên ngoài là tài khoản tài chính. Đổi lại, tài khoản tài chính được chia thành phân tích và tổng hợp. Các tài khoản phụ kế toán tài chính của RPS là trung gian giữa phân tích và tổng hợp. Hơn nữa, các tài khoản phân tích và tổng hợp tài chính cũng như các tài khoản phụ có thể là một phần không thể thiếu trong thành phần quản lý của RPS. Ví dụ: dữ liệu được phản ánh trong các tài khoản phụ riêng lẻ của tài khoản tài chính 90 “Doanh số” rất quan trọng để đưa ra quyết định quản lý.

Khi thành lập nhóm tài khoản tài chính của RPS phải đáp ứng các yêu cầu sau:

1. giữa các chỉ tiêu báo cáo kế toán bên ngoài và số dư tài khoản tài chính phải thiết lập được sự tương ứng mà không yêu cầu các thao tác logic bổ sung để xác định loại chỉ tiêu báo cáo;
2. bộ tài khoản tài chính tối thiểu có thể có của RPS phải được hình thành có mục đích dựa trên thành phần của các chỉ số báo cáo tài chính bên ngoài;
3. Mỗi chỉ số báo cáo tài chính bên ngoài phải được lấy từ dữ liệu kế toán tài chính sử dụng RPS mà không cần giải mã hoặc điều chỉnh bổ sung.

Thành phần thuế. Việc sử dụng RPS trong hệ thống kế toán cung cấp khả năng tính toán cơ sở tính thuế và số lợi nhuận cho mục đích tính thuế theo các yêu cầu của Chương. 25 Mã số thuế của Liên bang Nga. Việc thực hiện thành phần thuế của cách tiếp cận có hệ thống đối với RPS bao gồm:

1. tổ chức phân tích tài chính và kế toán thuế các chi phí và thu nhập để xác định tác động của chúng đến số tiền cơ sở tính thuế lợi tức của tổ chức thương mại bằng cách chi tiết các tài khoản tài chính (01 - 99) RPS;
2. xây dựng danh sách tài khoản thuế (ví dụ: 101–199). Việc thực hiện chúng sẽ giúp ghi lại những sai lệch trong số liệu kế toán của các đối tượng kế toán tài chính và thuế để lập kế toán thuế và báo cáo thuế trên cơ sở kế toán tài chính và báo cáo tài chính;
3. xây dựng các quy tắc cho phép điều chỉnh tác động của thành phần thuế lên báo cáo kế toán tích hợp thống nhất nhằm loại bỏ sự trùng lặp trong các chỉ số kế toán và phân tích (kết quả) báo cáo.

Thành phần quản lý. Trong RPS, để có được các chỉ số kế toán và phân tích kết quả của báo cáo nội bộ quản lý và kế toán quản lý, một khối tài khoản quản lý được phân bổ (ví dụ: 201–299). Trên các tài khoản quản lý này, việc điều chỉnh mục nhập kép cho tài khoản tài chính 01–99 được thực hiện dựa trên yêu cầu của người dùng về báo cáo quản lý nội bộ. Trong tương lai, dữ liệu về tài khoản quản lý 201–299, khi sử dụng một số quy tắc nhất định, sẽ bổ sung (sửa) dữ liệu về tài khoản tài chính 01–99. Kết quả của những hành động đó là các chỉ số báo cáo quản lý nội bộ.

Việc thực hiện khía cạnh quản lý theo cách tiếp cận có hệ thống để hình thành RPS liên quan đến việc phát triển:

1. các quy định về chính sách kế toán (bên ngoài và nội bộ), làm rõ các tiêu chí ghi nhận các khoản mục kế toán, đánh giá chúng cũng như công bố nội dung các khoản mục báo cáo quản lý;
2. hệ thống con tài khoản quản lý của RPS thống nhất, cần thiết để ghi lại và tóm tắt những sai lệch giữa dữ liệu kế toán quản trị với dữ liệu kế toán tài chính;
3. thành phần báo cáo tài chính thay thế của các mẫu báo cáo quản lý.

Ngoài ra, khi hình thành khối tài khoản quản lý cho RPS, cần xây dựng bảng “Mối quan hệ (ánh xạ) giữa các hệ thống con của tài khoản tài chính và quản lý với các chỉ số báo cáo quản lý thay thế”.

Bảng 2. Sơ đồ các hoạt động kế toán (tài chính) kế toán của Nga để tạo các dòng trong biểu mẫu báo cáo doanh nghiệp “Số dư” (trích xuất)

Vòng quay nợ

Hệ điều hành trong tổ chức

Các nhóm hệ điều hành:<все>

Đầu tư vào phi hiện tại
tài sản

Đừng thay đổi

Phân khu:<все>

Không thay đổi

Mã số dự án:<все>

Đừng mở ra

Tham gia kiểm soát nhóm với một điểm cộng

Tài sản cố định: Tài sản cố định khác

Dự án xây dựng (p): Loại Thu nhập từ tài sản cố định (Nhận từ bên thứ ba)

Vòng quay nợ

Hệ điều hành không cần đăng ký

Các nhóm hệ điều hành:<все>

Đừng thay đổi

Phân khu:<все>

Không thay đổi

Mã số dự án:<все>

Đừng mở ra

Tham gia kiểm soát nhóm với một điểm cộng

Tài sản cố định: Tài sản cố định khác

Dự án xây dựng (p): Loại Thu nhập từ tài sản cố định (Nhận từ bên thứ ba)

Vòng quay nợ

MC trong tổ chức

Đầu tư vào tài sản dài hạn

Đừng thay đổi

Không thay đổi

Đừng mở ra

Tham gia kiểm soát nhóm với một điểm cộng

(Các) Tài sản cố định: Loại thu nhập cố định (Biên nhận từ bên thứ ba)

Vòng quay nợ

MC, phía trước. sở hữu tạm thời

Nhà thầu:<все>

Đầu tư vào phi hiện tại
tài sản

Đừng thay đổi

Thỏa thuận:<все>

Không thay đổi

Mã số dự án:<все>

Đừng mở ra

Tham gia kiểm soát nhóm với một điểm cộng

Tài sản cố định: Tài sản cố định khác

Dự án xây dựng (p): Loại Biên nhận (Biên nhận từ bên thứ ba)

Vòng quay nợ

MC, phía trước. để sử dụng tạm thời

Nhà thầu:<все>

Đầu tư vào phi hiện tại
tài sản

Đừng thay đổi

Thỏa thuận:<все>

Không thay đổi

Mã số dự án:<все>

Đừng mở ra

Tham gia kiểm soát nhóm với một điểm cộng

	Đường cân bằng	Tài khoản kế toán	Lựa chọn theo tiểu mục 1	Đúng. tài khoản kế toán	Lựa chọn theo tiểu mục 1	Công thức lựa chọn
		Lựa chọn theo tiểu mục 2		Lựa chọn theo tiểu mục 2	Đảo ngược dấu hiệu
		Lựa chọn theo tiểu mục 3		Lựa chọn theo tiểu mục 3	kế toán thuế GTGT
		Lựa chọn theo tiểu mục 4		Lựa chọn theo tiểu mục 4	Mở rộng bằng
		Lựa chọn theo tiểu mục 5		Lựa chọn theo tiểu mục 5	Tham gia vào tài khoản nhóm
BL00102 Đưa vào vận hành (+)
Đưa vào hoạt động (+)
Đưa vào hoạt động (+)
Đưa vào hoạt động (+)
Đưa vào hoạt động (+)
Đưa vào hoạt động (+)

Không còn nghi ngờ gì nữa, quyết định tạo ra một hệ thống kế toán tích hợp (tài chính, thuế và quản lý) trong một tổ chức thương mại và phát triển một sơ đồ tài khoản làm việc thống nhất cho một hệ thống như vậy dựa trên Sơ đồ tài khoản tiêu chuẩn là không rõ ràng. Về mặt lý thuyết, có thể áp dụng các phương pháp sau để xây dựng sơ đồ kế toán làm việc cho một tổ chức thương mại (trong trường hợp sử dụng sơ đồ kế toán cho 3 loại hình kế toán):

• một biểu đồ tích hợp duy nhất về kế toán tài chính, thuế và quản lý;
• sơ đồ tích hợp kế toán tài chính và kế toán thuế, sơ đồ hạch toán tự chủ cho kế toán quản trị;
• sơ đồ tổng hợp kế toán tài chính và kế toán quản trị; hệ thống tài khoản tự chủ để hạch toán thuế;
• sơ đồ tổng hợp kế toán thuế và kế toán quản trị; sơ đồ hạch toán kế toán tài chính tự chủ;
• sơ đồ hạch toán tự chủ về tài chính, thuế và kế toán quản trị.

2. Các vấn đề về xây dựng sách tham khảo và bảng phân loại, trong đó chủ yếu là:

• sao chép thông tin trong thư mục;
• Mã hóa không chính xác của các thư mục thuật ngữ.

Ví dụ, điều thường xảy ra là không có quy trình thống nhất để gán mã và tên; cùng một đối tác có thể được liệt kê trong thư mục hai lần (Romashka LLC và Romashka LLC, các tùy chọn và kết hợp khác) hoặc dưới các tên khác nhau (ví dụ: dưới đầy đủ và viết tắt). Việc tìm kiếm các dữ liệu cần thiết trong hệ thống thông tin bằng các thư mục phi cấu trúc khá phức tạp và bất tiện. Ngoài ra, sự lộn xộn trong sách tham khảo còn gây ra sai sót trong báo cáo.

Ví dụ: mỗi doanh nghiệp là một phần của tổ chức, ở một mức độ nhất định, duy trì các hồ sơ chính một cách độc lập, phát triển và cập nhật các thư mục riêng của mình. Công việc này tại doanh nghiệp thường được thực hiện bởi các bộ phận dịch vụ khác nhau: bộ phận tài chính, bộ phận tiếp thị, bộ phận pháp lý, v.v. Tất cả điều này cho phép bạn đưa ra quyết định quản lý tối ưu trong một doanh nghiệp cụ thể. Tuy nhiên, sự hiểu biết và khả năng phân tích tình trạng hiện tại của toàn bộ tổ chức là rất khó khăn do tính chất thống nhất và không có cấu trúc của thông tin.

Một tình trạng phổ biến khác: tại một công ty, do bộ phận marketing thường xuyên yêu cầu bộ phận kế toán về cơ cấu bán hàng nên kế toán phải thu thập thông tin thủ công ở các phần thông tin cần thiết. Điều này là do bộ phận bán hàng không phải lúc nào cũng nhập dữ liệu cần thiết vào thư mục để tự động tạo các báo cáo được yêu cầu.

– Sự không tương thích giữa các bộ phận của hệ thống kế toán tự động.
Ví dụ: bộ phận cung ứng duy trì các sổ đăng ký và thư mục của ITC trong chương trình Cache, đồng thời các sổ đăng ký và thư mục kế toán (tài chính) và quản lý được duy trì trong SAP R3 và báo cáo của công ty cũng được tạo ở đó. Các định dạng trình bày dữ liệu trong các chương trình này khác nhau, do đó việc chuyển đổi dữ liệu giữa chúng rất khó và trong một số trường hợp là không thể thực hiện được.

Khi biên soạn sách tham khảo cần tuân thủ các nguyên tắc sau.

– Chi tiết và cấu trúc của các thư mục phải sao cho có thể xử lý dữ liệu nhanh chóng và tạo ra các báo cáo cần thiết.

Nếu sách tham khảo không đủ chi tiết sẽ gây khó khăn cho việc thu thập những thông tin cần thiết. Ví dụ: nếu vào giữa năm, bạn cần tìm hiểu về chi phí sản xuất tài liệu quảng cáo do bộ phận tiếp thị đặt hàng và trước đó tất cả các chi phí tiếp thị đã được tính cùng nhau, thì bạn sẽ cần phải lựa chọn thêm: thông tin dựa trên bằng chứng gián tiếp (ví dụ, từ các nhà in). (Đối với các công ty cổ phần hoặc nhóm công ty, mức độ chi tiết của danh bạ sẽ phụ thuộc vào yêu cầu cấu trúc thông tin không chỉ của một doanh nghiệp riêng lẻ mà còn của toàn bộ công ty nắm giữ.)

Nếu sách tham khảo quá chi tiết thì bạn khó có thể điền đầy đủ thông tin và sử dụng vào công việc của mình. Ví dụ: thư mục “Dòng tiền” có thể chứa hơn một nghìn mục đích thanh toán khác nhau. Việc chuẩn bị báo cáo dòng tiền cho các khoản thanh toán cơ bản cho tổng giám đốc sẽ mất rất nhiều thời gian, vì bạn sẽ phải thực hiện việc phân nhóm cần thiết (tổng hợp các chỉ số hoặc lựa chọn thông tin cần thiết từ một mảng thông tin dư thừa). Ngoài ra, khi nhập thông tin, người dùng có thể không biết nên đưa một khoản thanh toán cụ thể vào đâu. Điều này chắc chắn sẽ dẫn đến việc lựa chọn không chính xác các mục từ danh mục hoặc phân loại khoản thanh toán là “khác”. Có thể khuyến nghị mô tả chi tiết những đối tượng kế toán nào có thể được phản ánh cho từng dòng trong danh mục.

– Việc mã hóa các thành phần thư mục sẽ loại bỏ sự trùng lặp thông tin và giúp tăng tốc độ làm việc với thư mục. Trước khi mã hóa dữ liệu, cần xác định thư mục tham chiếu sẽ được lưu trữ trong hệ thống thông tin doanh nghiệp nào. Khả năng sử dụng một số mã nhất định sẽ phụ thuộc phần lớn vào khả năng của hệ thống. Hệ thống như vậy có thể là một chương trình kế toán, thông tin từ đó được tự động chuyển sang các hệ thống khác sử dụng cùng thư mục.

– Bạn nên tránh sử dụng các bảng mã giống nhau ở các thư mục khác nhau.
Ví dụ: nếu khi phân tích doanh số bán hàng, bộ phận tiếp thị xác định các nhóm người mua không phải theo khu vực mà theo thành phố và khu vực, thì các nhóm để phân tích không được trùng với mã của các khu vực liên bang. Nếu không sẽ dẫn đến sai sót khi nhập thông tin. Do đó, mã “77” được đặt cho Moscow và vùng Belgorod được liệt kê theo mã này tại doanh nghiệp. Kết quả là, một nhân viên có thể quy một loại hình bán hàng nhất định không phải cho khu vực mà là cho Moscow, và thông tin sẽ bị bóp méo. Trong trường hợp này, nên tạo các mã có độ dài khác nhau, chẳng hạn như để mã hóa các nhóm tiếp thị, sử dụng ba chữ số (mã “770” dành cho khách hàng ở vùng Belgorod);

– Lý tưởng nhất Mã thư mục không được vượt quá 8 ký tự. Nếu không, dữ liệu sẽ khó nhập vì các mã không dễ phân biệt với nhau.

– khi tạo các thư mục được kết nối với nhau, cần loại bỏ sự trùng lặp. Để tránh sai sót trong các thư mục (do tính chất thiếu hệ thống và hỗn loạn của việc điền chúng), cần phải phân tích thông tin chứa trong chúng để xác định dữ liệu có thể được tạo ra bởi các thư mục riêng lẻ.

– Đã phát triển một hệ thống thư mục thống nhất, cần đảm bảo bảo vệ nó khỏi những thay đổi trái phép. Mức độ bảo mật đủ cao thường có thể đạt được thông qua việc sử dụng các phương pháp nhận dạng người dùng và thông qua việc phân định quyền truy cập thông tin của người dùng. Thông thường, để tạo và duy trì các thư mục, các công ty xây dựng các quy định nhằm xác định những người chịu trách nhiệm nhập thông tin vào các thư mục và sửa đổi nó.

Tóm lại, cần phải nói rằng cần phải giải quyết các vấn đề trên trước khi thiết lập bản đồ. Nếu không thì khó có thể tạo được báo cáo quản lý. Ngay cả khi báo cáo được tạo ra thì khả năng nó đúng là gần như bằng không. Những lý do rất rõ ràng:

1. Lỗi sẽ xuất hiện do các vấn đề được mô tả trước đó.
2. Sai sót kế toán (cả về phương pháp và kế toán). Mọi người lưu giữ hồ sơ, đừng quên điều đó.
3. Tiếp theo, chúng ta nên đưa ra một danh sách dài các loại lỗi khác nhau, nguyên nhân của chúng sẽ là kết quả của sự chồng chất của đoạn 1 và 2. Tuy nhiên, theo chúng tôi, điều này là không cần thiết.