Мэппинг статей затрат

Порядок формирования трансформационной таблицы

Шаг 1. Создаем шаблон трансформационной таблицы. Настраиваем формулы.

Для удобства используем статьи баланса (БС) и отчета о финансовых результатах (ОФР), все статьи занимают один столбец и прописываются друг под другом в отдельных ячейках. Чем более продвинутая форма трансформационной таблицы — тем детальнее данные статьи. Например, следует написать не просто строку «административные расходы», а указать: зарплата, аренда, юридические услуги и т.д. Это в дальнейшем позволит сэкономить время на расшифровках отчетности.

Отметим, что набор статей баланса и отчета о финансовых результатах для каждой компании будет отличным. В МСФО нет регламентированной формы отчетов.

Также следует указать суммирующие строки: «Итого активы», «Итого обязательства», «Итого капитал и обязательства», «Прибыль до налогообложения», «Прибыль после налогообложения».

Для того чтобы не сделать ошибки при применении метода двойной записи, в трансформации лучше принять за правило, что все активы мы отражаем с плюсом, все пассивы с минусом, расходы с плюсом, доходы с минусом (либо, как альтернатива: активы с минусом, пассивы с плюсом, расходы с минусом, доходы с плюсом).

Например, корректировка:

  • Дебет26 Кредит70 =50 000 руб (начисление премии по итогам 2017 года) будет в трансформационной таблице представлена

  • ОФР: Зарплата (Дебет 26) + 50 000 (расход с плюсом)

  • БС: Кредиторская задолженность (Кредит 70) — 50 000 (пассив с отрицательным знаком)

  • (см. корректировку 2 в примере 1 Трансформационной таблицы)

Пример 1 Трансформационная таблица

ООО «Горошек», тысячи рублей, 2017 год РСБУ Корректировка 1 Корректировка 2 Корректировка 3 МСФО
Данные из ОСВ Списан товарный знак Начисление премии Реклас-сификация расходов
БС 1 2 3 4 5 (1+2+3+4)

АКТИВЫ

Товарный знак, созданный организацией самостоятель-но, в качестве нематериаль- ного актива в МСФО не признается (п. 63 МСФО (IAS) 38).

Приказ о премировании датирован 04.04.2018. Бухгалтерия по РСБУ данные затраты отражает в 2018 году. Для целей МСФО учитываем в 2017 году. (Концепции МСФО)

ИТОГО

Внеоборотные активы

Основные средства

50 000

50 000

Нематериальные активы

40 000

-40 000

Отложенные налоговые активы

Итого внеоборотные активы

90 000

-40 000

50 000

Оборотные активы

Денежные средства и эквиваленты

200 000

200 000

Дебиторская задолженность

60 000

60 000

Предоплата по налогу на прибыль

Запасы

30 000

30 000

Итого оборотные активы

290 000

290 000

Итого активы

380 000

-40 000

340 000

ОБЯЗАТЕЛЬСТВА

Долгосрочные обязательства

Отложенные налоговые обязательства

Долгосрочные заемные средства

Итого долгосрочные обязательства

Краткосрочные обязательства

Краткосрочные заемные средства

-235 000

-235 000

Кредиторская задолженность

-50 000

-50 000

Задолженность по налогу на прибыль

-15 000

Итого краткосрочные обязательства

КАПИТАЛ

Уставные капитал

-10 000

-10 000

Добавочный капитал

Нераспределенная прибыль

-40 000

-40 000

Прибыль текущего года

-80 000

40 000

50 000

-30 000

Итого капитал

-130 000

40 000

50 000

-40 000

Итого капитал и обязательства

-380 000

40 000

-340 000

Проверка (итого капитал и обязательства минус Итого Активы)

ОФР

Выручка

-290 000

−290 000

Себестоимость

150 000

150 000

Административные расходы

45 000

50 000

95 000

Амортизация

1 000

Заработная плата+ЕСН

40 000

+50 000

90 000

Представительские расходы

1 500

1 500

Услуги связи

Консультационные услуги

1 500

1 500

Прочие административные расходы

5 000

-4 500

Прочие доходы/расходы

Списание товарного знака

40 000

40 000

Финансовые доходы

Финансовые расходы

Прибыль/убыток до налогообложения

-95 000

40 000

50 000

-5 000

Налог на прибыль

15 000

15 000

Отложенные налоговые активы/обязательства

Прибыль/убыток за текущий период

-80 000

40 000

50 000

10 000

Шаг 2. Заполняем первый столбец трансформационной таблицы

Для получения исходных данных российской отчетности используют оборотно-сальдовую ведомость (ОСВ). Она должна быть сформирована с учетом субсчетов и развернутого сальдо по счетам расчетов. Данные из ОСВ следует разнести в первый столбец.

далее проверить, что работают контрольные соотношения: сумма прибыли текущего года в разделе Капитал равна прибыли за период в отчете о финансовых результатах (в нашем примере это −80 000) и в балансе Активы=Обязательства+Капитал.

Убедившись, что работают все проверочные формулы, переходим к шагу 3.

Шаг 3. Корректировки

Корректировки бывают двух видов:

  • Влияют на финансовый результат
  • Не влияют на финансовый результат

Особое внимание следует обратить на первые, именно из-за них отчетность по МСФО будет отличаться от РСБУ, а следовательно в будущем году мы должны вновь их повторить, но уже через нераспределенную прибыль. Это будут так называемые реверсивные проводки.

Нет универсального перечня корректировок, они для каждой компании рассчитываются индивидуально.

Анализируется каждая строка трансформации на предмет отличия в международной отчетности от РСБУ. Анализируются также операции, на предмет в правильном ли периоде они отражены.

В частности, в примере мы видим, что в данных по РСБУ есть нематериальные активы (НМА). Чтобы узнать в какой величине мы должны представить этот нематериальный актив в отчетности по МСФО нам необходимо понять, из чего состоят НМА в компании. Выясняем, что это — товарный знак, созданный самой организацией. В соответствии с п. 63, 64 МСФО (IAS) 38 торговые марки, созданные самой организацией, не подлежат признанию в качестве НМА, так как затраты на их создание невозможно отличить от затрат на развитие бизнеса. Данные затраты должны быть списаны в расход. Создаем корректировку № 1 в трансформационной таблице. Данная корректировка влияет на финансовый результат.

При дальнейшем анализе мы видим, бухгалтерия отразила начисление премии согласно первичному документу в 2018 году. Обратите внимание, при составлении отчетности по МСФО мы заглядываем «в будущее». Однако данная премия будет выплачена за работу 2017 года, и по принципам начисления должна быть отражена в МСФО в периоде, к которому относится. Поэтому корректировка 2 — это начисление премии. Данная корректировка тоже влияет на финансовый результат.

Далее, обращаем внимание, что статья «прочие административные расходы» не информативна для пользователей. При анализе выяснилось, что из 5 000 т.р. мы можем выделить Амортизацию на 1000 т.р., Представительские расходы на 1500 т.р., Услуги связи на 500 т.р. и Консультационные услуги на 1500 т.р. Не расшифрованными остается 500 т.р.

Данная операция не повлекла за собой изменение финансового результата, мы просто выделили расходы из одной строки в четыре строки. Это второй вид корректировок.

В примере мы не будем рассчитывать отложенный налог по МСФО, а ограничимся тремя корректировками. На практике корректировок обычно больше. Итоговый столбец содержит в себе данные по МСФО. Эти данные впоследствии будут перенесены в Отчет о финансовом положении (так называется баланс по МСФО) и в Отчет о прибыли и убытке и прочем совокупном доходе МСФО.

Однако, интересно посмотреть как будет выглядеть трансформационная таблица в 2018 году? Для простоты предположим, что у нас не было никакой деятельности, мы не выплачивали зарплату, не начисляли амортизацию и т.д. Но мы помним, что бухгалтерия сделала проводку по начислению премии в апреле 2018. Эту операцию мы учтем, тогда наши «входящие» данные по РСБУ из ОСВ будут выглядеть таким образом (см. столбец 1 примера 2 Трансформационная таблица)

Пример 2 Трансформационная таблица

ООО «Горошек», тысячи рублей, 2018 год РСБУ Вступительная проводка 1 Вступительная проводка 2 Коррек-тировка XX МСФО
Данные из ОСВ Списан товарный знак Начисление премии
БС 1 2 3 4 5(1+2+3+4)

АКТИВЫ

Товарный знак, созданный организацией самостоятельно, в качестве нематериального актива в МСФО не признается (п. 63 МСФО (IAS) 38).

Приказ о премировании датирован 04.04.2018. Бухгалтерия по РСБУ данные затраты отражает в 2018 году. Для целей МСФО учитываем в 2017 году. (Концепции МСФО)

ИТОГО

Внеоборотные активы

Основные средства

50 000

50 000

Нематериальные активы

40 000

-40 000

Отложенные налоговые активы

Итого внеоборотные активы

90 000

-40 000

50 000

Оборотные активы

Денежные средства и эквиваленты

200 000

200 000

Дебиторская задолженность

60 000

60 000

Предоплата по налогу на прибыль

Запасы

30 000

30 000

Итого оборотные активы

290 000

290 000

Итого активы

380 000

-40 000

340 000

ОБЯЗАТЕЛЬСТВА

Долгосрочные обязательства

Отложенные налоговые обязательства

Долгосрочные заемные средства

Итого долгосрочные обязательства

Краткосрочные обязательства

Краткосрочные заемные средства

-235 000

Кредиторская задолженность

-50 000

Задолженность по налогу на прибыль

-15 000

Итого краткосрочные обязательства

КАПИТАЛ

Уставные капитал

-10 000

-10 000

Добавочный капитал

Нераспределенная прибыль

-120 000

40 000

50 000

-30 000

Прибыль текущего года

50 000

-50 000

Итого капитал

-80 000

40 000

-40 000

Итого капитал и обязательства

-380 000

40 000

-340 000

проверка (итого капитал и обязательства минус Итого Активы)

ОФР

Выручка

Себестоимость

Административные расходы

50 000

-50 000

Амортизация

Заработная плата+ЕСН

50 000

-50 000

Представительские расходы

Услуги связи

Расходы на создание товарного знака

Консультационные услуги

Прочие административные расходы

Прочие доходы/расходы

Списание товарного знака

Финансовые доходы

Финансовые расходы

Прибыль/убыток до налогообложения

50 000

-50 000

Налог на прибыль

Отложенные налоговые активы/обязательства

Прибыль/убыток за текущий период

50 000

-50 000

Далее разберемся с данными по МСФО. Первое, что мы должны сделать — откорректировать нераспределенную прибыль. Как помните, в 2017 году у нас были две операции, влияющие на финансовый результат. Теперь они должны отражаться в нераспределенной прибыли по МСФО. Для этого мы делаем вступительные проводки.

В 2018 году товарный знак по-прежнему находится в нематериальных активах по РСБУ, следовательно, нам необходимо снова его списать, но т.к. расходы по списанию мы в МСФО понесли уже в 2017 году, теперь можем смело отнести данную операцию в нераспределенную прибыль.

Со второй корректировкой иная ситуация. В 2017 году мы отразили в МСФО расход по премии на 50 000 т.р. В 2018 году эти же 50 000 т.р. вошли из ОСВ как расход по данным РСБУ. Значит, чтобы не было дважды признания одного и того же расхода в разных периодах, нам необходимо вступительной проводкой откорректировать ОФР РСБУ против нераспределенной прибыли МСФО. Обратите внимание на вступительную проводку 2 в примере 2 Трансформационная таблица. Финансовый результат от этой операции равен нулю (в разделе Капитал нераспределенная прибыль +50 000 т.р. и прибыль текущего года −50 000т.р.; в ОФР по строке Заработная плата+ЕСН в итоге тоже ноль).

Часть 2. Создание классов, маппингов и заполнение БД

КЛАССЫ И МАППИНГИ
Уроки по FluentNHibernate c ASP.NET MVC и SQL Server. Часть 1
Часть 3. Отображение данных из таблицы (Операция LIST)
В предыдущей части были рассмотрены виды связей (один-к-одному, один-ко-многим, многие-ко-многим), а также один класс Book и его маппинг-класс BookMap. Во второй части обновим класс Book, создадим остальные классы и связи между ними, как это было изображено в предыдущей главе в Диаграмме баз данных, расположившейся над подзаголовком 1.3.1 Связи.
Код классов и маппингов (С комментариями) Класс Книга
public class Book { //Уникальный идентификатор public virtual int Id { get; set; } //Название public virtual string Name { get; set; } //Описание public virtual string Description { get; set; } //Оценка Мира фантастики public virtual int MfRaiting { get; set; } //Номера страниц public virtual int PageNumber { get; set; } //Ссылка на картинку public virtual string Image { get; set; } //Дата поступления книги (фильтр по новинкам!) public virtual DateTime IncomeDate { get; set; } //Жанр (Многие-ко-Многим) //Почему ISet а не IList? Только одна коллекция (IList) может выбираться с помощью JOIN выборки, если нужно более одной коллекции для выборки JOIN, то лучше их преобразовать в коллекцию ISet public virtual ISet<Genre> Genres { get; set; } //Серия (Многие-к-одному) public virtual Series Series { get; set; } //Мнение и другое (Один-к-одному) private Mind _mind; public virtual Mind Mind { get { return _mind ?? (_mind = new Mind()); } set { _mind = value; } } //Автор (Многие-ко-многим) public virtual ISet<Author> Authors { get; set; } //Заранее инициализируем, чтобы исключение null не возникало. public Book() { //Неупорядочное множество (в одной таблице не может присутствовать две точь-в-точь одинаковые строки, в противном случае выбирает одну, а другую игнорирует) Genres = new HashSet<Genre>(); Authors = new HashSet<Author>(); } } //Маппинг класса Book public class BookMap : ClassMap<Book> { 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); //Отношение многие-ко-многим HasManyToMany(x => x.Genres) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и //создаются/обновляются/добавляются все зависимые объекты .Cascade.SaveUpdate() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Genre! .Table(«Book_Genre»); HasManyToMany(x => x.Authors) .Cascade.SaveUpdate() .Table(«Book_Author»); //Отношение многие к одному References(x => x.Series); //Отношение один-к-одному. Главный класс. HasOne(x => x.Mind).Cascade.All().Constrained(); } }
Класс Автор
public class Author { public virtual int Id { get; set; } //Имя-Фамилия public virtual string Name { get; set; } //Биография public virtual string Biography { get; set; } //Книжки public virtual ISet<Book> Books { get; set; } //Инициализация Авторов public Author() { Books=new HashSet<Book>(); } } //Маппинг Автора public class AuthorMap : ClassMap<Author> { public AuthorMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.Biography); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты .Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table(«Book_Author»); } }
Класс Жанр
public class Genre { public virtual int Id { get; set; } //Название жанра public virtual string Name { get; set; } //Английское название жанра public virtual string EngName { get; set; } //Книжки public virtual ISet<Book> Books { get; set; } //Инициализация книг public Genre() { Books=new HashSet<Book>(); } } //Маппинг жанра public class GenreMap : ClassMap<Genre> { public GenreMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.EngName); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты .Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table(«Book_Genre»); } }
Класс Мнение:
public class Mind { public virtual int Id { get; set; } //Мое мнение public virtual string MyMind { get; set; } //Мнение фантлаба public virtual string MindFantLab { get; set; } //Книга public virtual Book Book { get; set; } } //Маппинг Мind public class MindMap:ClassMap<Mind> { public MindMap() { Id(x => x.Id); Map(x => x.MyMind); Map(x => x.MindFantLab); //Отношение один к одному HasOne(x => x.Book); } }
Класс Цикл(Серия):
public class Series { public virtual int Id { get; set; } public virtual string Name { get; set; } //Я создал IList, а не ISet, потому что кроме Book, Series больше ни с чем не связана, хотя можно сделать и ISet public virtual IList<Book> Books { get; set; } //Инициализация книг. public Series() { Books = new List<Book>(); } } public class SeriesMap : ClassMap<Series> { public SeriesMap() { Id(x => x.Id); Map(x => x.Name); //Отношение один-ко-многим HasMany(x => x.Books) ////Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() } }
Небольшое объяснение
public virtual ISet<Genre> Genres { get; set; }
public virtual ISet<Author> Authors { get; set; }
Почему ISet<Class>, а не, к примеру, привычный многим IList<Class>? Если использовать вместо ISet — IList, и попробовать запустить проект, то разницы особой мы не заметим (Таблицы и классы создадутся). Но когда мы к классу Book LeftJoin-им одновременно таблицу Genre и Authors, да и еще пытаемся вывести неповторяющиеся записи из таблицы Book (Distinct Book.Id) в представление (View), Nhibernate выдаст исключение и ошибку.
Cannot simultaneously fetch multiple bags.
В таких случаях используем ISet, тем более множества для этого и предназначены (игнорируют дублирующие записи).
Отношение многие-ко-многим.

В NHibernate есть понятие, «главной» таблицы. Хотя отношения «многие-ко-многим» между таблицами “Book” и “Автор” равнозначны (У автора может быть много книг, у книги может быть множество авторов), Nhibernate требует, чтобы программист указывал таблицу, которая сохраняется второй (имеет метод .inverse()), то есть вначале будет создана/обновлена/удалена запись в таблице Book, а только потом в таблице Author.
Cascade.All означает выполнение каскадных операций при save-update и delete. То есть когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты (Ps. Можно прописать вместо Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Метод .Table(«Book_Author»); создает «промежуточную» таблицу “Book_Author” в БД.
Отношение многие-к-одному, один-ко-многим.

Book Series
References(x => x.Series).Cascade.SaveUpdate(); HasMany(x => x.Books)
.Inverse();

Метод References применяется на стороне «Многие-к-одному», на другой стороне «Один-ко-многим» будет метод HasMany.
Отношение один-к-одному

Book Mind
HasOne(x => x.Mind).Cascade.All().Constrained(); HasOne(x => x.Book);

Метод .Constrained() говорит NHibernate, что для записи из таблицы Book должна соответствовать запись из таблицы Mind (id таблицы Mind должен быть равен id таблицы Book)
Если сейчас запустить проект и посмотреть БД Bibilioteca, то появятся новые таблицы с уже сформированными связями.
Далее заполним созданные таблицы данными…
Для этого создадим тестовое приложение, которое будет сохранять данные в БД, обновлять и удалять их, изменив HomeController следующим образом (Ненужные участки кода комментируем):
public ActionResult Index() { using (ISession session = NHibernateHelper.OpenSession()) { using (ITransaction transaction = session.BeginTransaction()) { //Создать, добавить var createBook = new Book(); createBook.Name = «Metro2033»; createBook.Description = «Постапокалипсическая мистика»; createBook.Authors.Add(new Author { Name = «Глуховский» }); createBook.Genres.Add(new Genre { Name = «Постапокалипсическая мистика» }); createBook.Series = new Series { Name = «Метро» }; createBook.Mind = new Mind { MyMind = «Постапокалипсическая мистика» }; session.SaveOrUpdate(createBook); //Обновить (По идентификатору) //var series = session.Get<Series>(1); //var updateBook = session.Get<Book>(1); //updateBook.Name = «Metro2034»; //updateBook.Description = «Антиутопия»; //updateBook.Authors.ElementAt(0).Name = «Глуховский»; //updateBook.Genres.ElementAt(0).Name = «Антиутопия»; //updateBook.Series = series; //updateBook.Mind.MyMind = «11111»; //session.SaveOrUpdate(updateBook); //Удаление (По идентификатору) //var deleteBook = session.Get<Book>(1); //session.Delete(deleteBook); transaction.Commit(); } Genre genreAl = null; Author authorAl = null; Series seriesAl = null; Mind mindAl = null; var books = session.QueryOver<Book>() //Left Join с таблицей Genres .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Authors, () => authorAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Series, () => seriesAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Mind, () => mindAl, JoinType.LeftOuterJoin) //Убирает повторяющиеся id номера таблицы Book. .TransformUsing(Transformers.DistinctRootEntity).List(); return View(books); } }

Небольшое объяснение

  1. var books = session.QueryOver<Book>() — подобно выполнению скрипта SQL: Select * From Book;
  2. .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin) — подобно выполнению скрипта SQL:
    SELECT *FROM Book
    inner JOIN Book_Genre ON book.id = Book_Genre.Book_id
    LEFT JOIN Genre ON Book_Genre.Genre_id = Genre.id
  3. .TransformUsing(Transformers.DistinctRootEntity) — Подобно выполнению скрипта SQL: SELECT distinct Book.Id…, (убирает дублирующие записи с одинаковыми id)

Виды объединений
.JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin)

  1. LeftOuterJoin — выбирает все записи из левой таблицы (Book), а затем присоединяет к ним записи правой таблицы (Genre). Если не найдена соответствующая запись в правой таблицы, отображает её как Null
  2. RightOuterJoin действует в противоположность LEFT JOIN — выбирает все записи из правой таблицы (Genre), а затем присоединяет к ним записи левой таблицы (Book)
  3. InnerJoin — выбирает только те записи из левой таблиц (Book) у которой есть соответствующая запись из правой таблицы (Genre), а затем присоединяет к ним записи из правой таблицы

Изменим представление следующим образом:
Представление index @model IEnumerable<NhibernateMVC.Models.Book> @{ Layout = null; } <!DOCTYPE html> <html> <head> <meta name=»viewport» content=»width=device-width» /> <title>Index</title> <style> th, td { border: 1px solid; } </style> </head> <body> <p>@Html.ActionLink(«Create New», «Create»)</p> <table> <tr> <th>@Html.DisplayNameFor(model => model.Name)</th> <th>@Html.DisplayNameFor(model => model.Mind)</th> <th>@Html.DisplayNameFor(model => model.Series)</th> <th>@Html.DisplayNameFor(model => model.Authors)</th> <th>@Html.DisplayNameFor(model => model.Genres)</th> <th>Операции</th> </tr> @foreach (var item in Model) { <tr> <td>@Html.DisplayFor(modelItem => item.Name)</td> <td>@Html.DisplayFor(modelItem => item.Mind.MyMind)</td> @{string strSeries = item.Series != null ? item.Series.Name : null;} <td>@Html.DisplayFor(modelItem => strSeries)</td> <td> @foreach (var author in item.Authors) { string strAuthor = author != null ? author.Name : null; @Html.DisplayFor(modelItem => strAuthor) <br /> } </td> <td> @foreach (var genre in item.Genres) { string strGenre = genre!= null ? genre.Name : null; @Html.DisplayFor(modelItem => strGenre) <br /> } </td> <td> @Html.ActionLink(«Edit», «Edit», new { id = item.Id }) | @Html.ActionLink(«Details», «Details», new { id = item.Id }) | @Html.ActionLink(«Delete», «Delete», new { id = item.Id }) </td> </tr> } </table> </body> </html>
Проверив поочередно все операции, мы заметим, что:

  • При операциях Create и Update обновляются все данные, связанные с таблицей Book (уберите Cascade=»save-update» или cascade=»all» и связанные данные не будут сохранены)
  • При удалении удаляются данные из таблиц Book, Mind, Book_Author, а остальные данные не удаляются, потому что у них Cascade=»save-update»
  • При удалении удаляются данные из таблиц Book, Mind, Book_Author, а остальные данные не удаляются, потому что у них Cascade=»save-update»

Маппинг для классов, у которых есть наследование.
А как маппить классы у которых есть наследование? Допустим, имеем такой пример:
//Класс Двумерных фигур public class TwoDShape { //Ширина public virtual int Width { get; set; } //Высота public virtual int Height { get; set; } } //Класс треугольник public class Triangle : TwoDShape { //Идентификационный номер public virtual int Id { get; set; } //Вид треугольника public virtual string Style { get; set; } }
В принципе, ничего сложного в этом маппинге нет, мы просто создадим один маппинг для производного класса, то есть таблицы Triangle.

Оставьте комментарий