• Начало
  •  > 
  • полезно
  •  > 
  • Технология за миграция на данни в големи проекти. "Mapping" е нов инструмент за LPgenerator! Индивидуални файлове за показване

Технология за миграция на данни в големи проекти. "Mapping" е нов инструмент за LPgenerator! Индивидуални файлове за показване

проблем

Изтеглили сте отчет за отчитане на разходите и искате да го покажете на ръководството. За да направите това, трябва да съставите данните за статията счетоводство- по статии на управленското счетоводство. Знаете как счетоводството и счетоводните статии са свързани помежду си, но всеки път ръчното изготвяне на такъв отчет ви отнема твърде много време.

Решение

Ще разглеждаме този случай като продължение на предишния. Нека си представим, че сте създали следната директория в Excel:

Фиг.2.1. Справочник: картографиране на статиите на BU и CU


Отляво е разходна позиция (AC), отдясно е управленска счетоводна позиция (MA). Важно е разходната позиция да се появява само веднъж в първата колона, в противен случай механизмът за картографиране няма да работи правилно.

(Между другото, английската дума mapping се превежда като показване или кореспонденция, така че справочникът в в този случай- това е определено общо правило за това как статиите на BU се отразяват в статиите на OU).

Фиг.2.2. Плоска таблица: отчет за разходите (от "Оборот по сметка 20")


Моля, имайте предвид, че в 7-ма колона се е появила колоната „TC на статията“. Срещу всяка разходна позиция сме поставили позиция за управленско счетоводство. Това може да се направи ръчно, но е много по-удобно да използвате този инструмент:

Фиг.2.3. Плоска таблица: отчет за разходите (от "Оборот по сметка 20")


В долната част на формуляра са посочени имената на страниците: „Начало“ е плоска таблица, която съдържа данни за разходите (фиг. 2.2), „spr“ е справочна книга (фиг. 2.1).

Номерата на колоните са посочени в горната част на формуляра. И така, в този случай, ако данните в колони 1 на директорията и 3 на главната страница съвпадат, тогава данните от 2-ра колона на директорията се копират в 7-ма колона на главната страница.

Тази форма има и много допълнителни опции. Например, можете да активирате квадратчетата за отметка „Атрибут #2“ и „Атрибут #3“ и след това прехвърлянето на данни от колона 2 на директорията в колона 7 на главната страница ще бъде възможно, ако директорията и главната страница съвпадат с две или дори три детайла наведнъж.

В резултат на такава проста операция, като използвате обобщена таблица, можете да изградите цяла поредицаразлични аналитични доклади, в които един от разделите ще включва анализатора „Статия UU“. Например така:

Фиг.2.4. Разходна справка за арматурен цех


Сравнение на картографиране с VLOOKUP()

Много потребители са запознати и използват функцията VLOOKUP() в подобни ситуации. Функцията VLOOKUP() обаче работи добре само при малки обемиданни, докато този формуляр върши отлична работа за обработка на таблици на Excel, дори ако имате, да речем, 5000 реда в справочника и 300 000 реда на страницата goav. Опитайте да го проверите и ще видите, че VLOOKUP() се проваля при такива обеми. Освен това функцията VLOOKUP() създава значително натоварване на Excel, принуждавайки го да извършва големи количества изчисления. Формата за картографиране избягва този недостатък: тя се изпълнява веднъж, продължава няколко секунди (за големи обеми от минути) и след това няма допълнително натоварване на Excel файлвече не се създава.


В предишната част разгледахме типовете връзки (едно към едно, едно към много, много към много), както и един клас Book и неговия клас за картографиране BookMap. Във втората част ще актуализираме класа Book, ще създадем останалите класове и връзки между тях, както беше изобразено в предишната глава в диаграмата на базата данни, разположена над подзаглавието 1.3.1 Връзки.

Код на класовете и съпоставянията (С коментари)

Класна книга

Публичен клас Книга ( //Уникален идентификатор public virtual int Id ( get; set; ) // Заглавие public virtual string Name ( get; set; ) // Описание public virtual string Description ( get; set; ) // Рейтинг на света of Fiction public virtual int MfRaiting ( get; set; ) //Номера на страници public virtual int PageNumber ( get; set; ) //Връзка към картината public virtual string Изображение (get; set; ) //Дата на пристигане на книгата (филтър по нови елементи!) public virtual DateTime IncomeDate ( get; set; ) //Genre (Many-to-Many) //Защо ISet, а не IList? Само една колекция (IList) може да бъде избрана чрез JOIN fetch, ако има повече от една е необходима колекция за JOIN извличане, тогава е по-добре да ги конвертирате в публична виртуална ISet колекция на ISet Жанрове ( get; set; ) // Серии (много към едно) публични виртуални серии серии ( get; set; ) // Мнение и други (едно към едно) частни Mind _mind; public virtual Mind Mind ( get ( return _mind ?? (_mind = new Mind()); ) set ( _mind = value; ) ) //Author (Many-to-many) public virtual ISet Автори ( get; set; ) //Инициализиране предварително, така че да не се появи нулево изключение. (); ) ) //Клас за картографиране Book public class 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.IncomeDate); //Отношение много към много (x => x.Genres) //Каскадни правила Всички - Когато обектът се записва, актуализира или изтрива, всички зависими обекти се проверяват и //created/updated/added.Cascade.SaveUpdate() //Името на междинната таблица ТРЯБВА да бъде същото като класа Genre .Table("Book_Genre" ); => x.Mind).Cascade.All().Constrained(); Публичен клас Автор ( публичен виртуален int Id ( get; set; ) // Име-Фамилия публичен виртуален низ Име ( get; set; ) // Биография публичен виртуален низ Биография ( get; set; ) // Книги публичен виртуален ISet Книги ( get; set; ) //Инициализиране на автори public Author() ( Books=new HashSet ();

) ) // Съпоставяне на автор публичен клас AuthorMap: ClassMap

( public AuthorMap() ( Id(x => x.Id); Map(x => x.Name); Map(x => x.Biography); //Връзката много към много HasManyToMany(x => x .Books) //Каскадни правила Всички - Когато даден обект е запазен, актуализиран или изтрит, всички зависими обекти се проверяват и създават/актуализират/добавят.Cascade.All() //Собственикът на колекцията е другият край на връзката (Книга) и тя ще бъде запазена първа. Клас Жанр Публичен клас Жанр ( публичен виртуален int Id ( get; set; ) // Име на жанра публичен виртуален низ Име ( get; set; ) // Английско име на жанра публичен виртуален низ EngName ( get; set; ) // Книги публичен виртуален ISet ( public GenreMap() ( Id(x => x.Id); Map(x => x.Name); Map(x => x.EngName); //Връзката много към много HasManyToMany(x => x .Books) //Каскадни правила Всички - Когато даден обект е запазен, актуализиран или изтрит, всички зависими обекти се проверяват и създават/актуализират/добавят.Cascade.All() //Собственикът на колекцията е другият край на връзката (Книга) и тя ще бъде запазена първа.

Становище на класа:

Публичен клас Mind ( публичен виртуален int Id ( get; set; ) //Моето мнение публичен виртуален низ MyMind ( get; set; ) // Мнението на Fantlab публичен виртуален низ MindFantLab ( get; set; ) // Book public virtual Book Book ( get; set;) //Mapping public class MindMap:ClassMap ( public MindMap() ( Id(x => x.Id); Map(x => x.MyMind); Map(x => x.MindFantLab); //Връзка едно към едно HasOne(x => x .Книга ) )

Цикъл на класа (серия):

Публичен клас Series ( public virtual int Id ( get; set; ) public virtual string Name ( get; set; ) //Създадох IList, а не ISet, защото освен Book, Series не е свързан с нищо друго, въпреки че вие може да прави и ISet публичен виртуален IList Книги ( get; set; ) //Инициализиране на книги. public Series() ( Книги = нов списък ();

) ) публичен клас SeriesMap: ClassMap
( public SeriesMap() ( Id(x => x.Id); Map(x => x.Name); //Връзката "един към много" HasMany(x => x.Books) ////Собственик на колекция . другия край на връзката (Книга) и тя ще бъде запазена първа. Малко пояснение
публичен виртуален ISet Жанрове (get; set;)

публичен виртуален ISet Автори ( get; set; ) Защо ISet
, а не например познатия на мнозина IList
? Ако използваме IList вместо ISet и се опитаме да стартираме проекта, няма да забележим голяма разлика (ще бъдат създадени таблици и класове). Но когато добавим таблиците Genre и Authors към класа Book LeftJoin едновременно и също се опитаме да покажем неповтарящи се записи от таблицата Book (Distinct Book.Id) в изглед (View), Nhibernate ще хвърли изключение и грешка.

Не могат да се изтеглят едновременно няколко чанти.

NHibernate има концепцията за „главна“ таблица. Въпреки че връзката много към много между таблиците Book и Author е еквивалентна (Един автор може да има много книги, една книга може да има много автори), Nhibernate изисква от програмиста да посочи таблицата, която се съхранява на второ място (има метод. inverse ()), тоест първо ще бъде създаден/актуализиран/изтрит запис в таблицата Книга и едва след това в таблицата Автор.
Cascade.All означава извършване на каскадни операции при запазване-актуализиране и изтриване. Тоест, когато даден обект се записва, актуализира или изтрива, всички зависими обекти се проверяват и създават/актуализират/добавят (Ps. Може да се напише вместо Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Method.Table("Book_Author"); създава „междинна“ таблица „Book_Author“ в базата данни.

Връзка много към едно, едно към много.

Методът.Constrained() казва на NHibernate, че запис от таблицата Book трябва да съответства на запис от таблицата Mind (идентификаторът на таблицата Mind трябва да е равен на идентификатора на таблицата Book)

Ако сега стартирате проекта и разгледате базата данни на Bibilioteca, ще се появят нови таблици с вече формирани връзки.

След това нека попълним създадените таблици с данни...
За да направим това, ще създадем тестово приложение, което ще записва данни в базата данни, ще ги актуализира и изтрива, променяйки HomeController, както следва (Ние коментираме ненужните секции от кода):
public ActionResult Index() ( using (ISession session = NHibernateHelper.OpenSession()) ( using (ITransaction transaction = session.BeginTransaction()) ( //Create, add var createBook = new Book(); createBook.Name = "Metro2033" ; createBook.Description = "Пост-апокалиптична мистика"; createBook.Authors.Add(Наименование = "Глуховски" )); ( Name = "Metro" ); createBook.Mind = new Mind ( MyMind = "Post-apocalyptic mysticism" ); session.SaveOrUpdate(createBook); //Update (By ID) //var series = session.Get (1); //var updateBook = session.Get (1); //session.Delete(deleteBook);

) ) публичен клас SeriesMap: ClassMap

  1. транзакция.Комит(); () ) Жанр genreAl = нула; Автор authorAl = нула; Серия серия Al = нула; Mind mindAl = нула;;
  2. var books = session.QueryOver() //Ляво съединение с таблица Жанрове .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) //Премахване на дублиращи се идентификационни номера на таблици Book.TransformUsing(Transformers.DistinctRootEntity List). (); връщане Преглед(книги);
    var books = session.QueryOver
    Изберете * От книга
    .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin)
  3. - подобно на изпълнение на SQL скрипт:ИЗБЕРЕТЕ *ОТ Книга вътрешен JOIN Book_Genre ON book.id = Book_Genre.Book_id LEFT JOIN Genre ON Book_Genre.Genre_id = Genre.id

.TransformUsing(Transformers.DistinctRootEntity)
var books = session.QueryOver

  1. - Подобно на изпълнение на SQL скрипт: ИЗБЕРЕТЕ отделен Book.Id..., (премахва дублиращи се записи със същия идентификатор) Видове асоциации LeftOuterJoin - избира всички записи от лявата таблица (
  2. книга Видове асоциации), и след това добавя правилните записи на таблица към тях ( ИЗБЕРЕТЕ отделен Book.Id...)
  3. Жанр ИЗБЕРЕТЕ отделен Book.Id...). Ако съответният запис не бъде намерен в дясната таблица, той се показва като Null Видове асоциации RightOuterJoin е обратното на LEFT JOIN - избира всички записи от дясната таблица (

), и след това добавя записите от лявата таблица към тях (

InnerJoin - избира само онези записи от левите таблици (

), който има съответен запис от дясната таблица ( ), и след това ги обединява със записи от дясната таблица Нека променим представянето, както следва:

Индексен изглед

@Html.DisplayNameFor(model => model.Series) Операции }
@model IEnumerable @( Layout = null; ) Индекс @Html.ActionLink("Създаване на нов", "Създаване") @Html.DisplayNameFor(модел => model.Name) @Html.DisplayNameFor(модел => model.Mind)
@Html.DisplayNameFor(модел => модел.Автори) @Html.DisplayNameFor(модел => модел.Жанрове)@foreach (променлив елемент в модела) ( @Html.DisplayFor(modelItem => item.Name)
} 		@Html.DisplayFor(modelItem => item.Mind.MyMind)
} 		@Html.ActionLink("Редактиране", "Редактиране", ново ( id = item.Id )) |




@Html.ActionLink("Детайли", "Детайли", ново ( id = item.Id )) |
  • @Html.ActionLink("Изтриване", "Изтриване", ново ( id = item.Id ))
  • След като проверихме всички операции една по една, ще забележим, че:

По време на операциите за създаване и актуализиране всички данни, свързани с таблицата на книгата, се актуализират (премахнете Cascade="save-update" или cascade="all" и свързаните данни няма да бъдат запазени)
При изтриване данните се изтриват от таблиците Book, Mind, Book_Author, но останалите данни не се изтриват, защото имат Cascade="save-update"
Картографиране за класове, които имат наследяване.

Как да картографирате класове, които имат наследяване? Да кажем, че имаме този пример:
//Клас от двуизмерни фигури public class TwoDShape ( //Width public virtual int Width ( get; set; ) // Height public virtual int Height ( get; set; ) ) // Class Triangle public class Triangle: TwoDShape ( / /Идентификационен номер public virtual int Id ( get; set; ) //Тип на триъгълника public virtual string Style ( get; set; ) ) По принцип няма нищо сложно в това картографиране; просто ще създадем едно картографиране за производния клас, тоест таблицата Triangle.
//Публичен клас за картографиране на триъгълник TriangleMap: ClassMap

( public TriangleMap() ( Id(x => x.Id); Map(x => x.Style); Map(x => x.Height); Map(x => x.Width); ) )

  • След стартиране на приложението в базата данни на Библиотека ще се появи следната (празна) таблица
  • Тагове:
  • asp.net mvc 4
nhibernate

sql сървър Добавете таговеБързото и качествено вземане на решения от ръководството на предприятието зависи от добре изградената система за управленско счетоводство в компанията. Управленско счетоводствотук в съответствие с общоприетата практика

  • този срок
  • означава използването на принципите на счетоводството и финансовото управление за решаване на проблеми в следните области на предприятието:
  • разработване и прилагане на бизнес стратегия;
  • осъществяване на планиране и контрол;
  • ефективно използване на ресурсите;
  • повишаване на оперативната ефективност;

запазване на материални и нематериални активи; управление на корпоративни и вътрешнофирмени бизнес процесиВъв всеки случай достъпът до информацията за акаунта се осъществява с помощта на

различни видове доклади.. Обемът на събираната информация се определя от ръководството на дружеството като компромисно решение между изискванията на държавните и регулаторните органи за разкриване на информация и максималния обем информация (финансова, технологична, статистическа), възникваща в процеса на стопанска дейност на предприятието. .

Най-ефективният начин за използване на информацията, генерирана в процеса на дейност, е създаването на хранилище за данни (datewarehouse), на базата на което, използвайки OLAP технологиите, всеки мениджър на предприятието може да генерира отчет за анализ на данни в аналитичния контекст, от който се нуждае и си предоставя информация за вземане на решения.

Понастоящем обаче най-често срещаният вариант остава създаването на информационна система, в която се натрупват данни и като правило има персонализиран генератор на отчети, който допълва стандартните отчети, предоставени от разработчика на системата.

Обикновено разработчици софтуерпредлагат на потребителите редовно актуализирани форми на външни (за регулаторните органи) отчети (счетоводни и данъчни) и рекламират възможността за създаване на всякакви видове отчети за управление, изисквани от предприятието. Генерираният отчет обаче не е непременно добре оформен.
Предприятието остава само с проблема за правилното генериране (попълване) на отчети.

Необходимостта едно предприятие да генерира отчетност в съответствие с международните стандарти може само да влоши ситуацията.

Ключовият момент при отчитането във всички случаи е необходимостта от създаване на връзка между идентификационните данни в информационните системи и съответните полета във формите за отчитане.

Възможни са следните варианти за организиране на връзката:

  • Под формата на таблица, описваща връзките или съответствието между полетата на отчета и данните в системата (последвана от записване на алгоритъм за автоматично генериране на отчет).
  • Чрез ръчно избиране на необходимата информация (с пълна липса на възможност за автоматизиране на отчета).
  • Смесен вариант, който изисква наличието на взаимовръзъчни таблици и ръчно декодиране и корекции при генериране на справки.

Първият вариант за организиране на връзката на информационните счетоводни системи с отчетните форми (чрез таблици, описващи връзките) се нарича „ картографиране“.

Картографирането (в широк смисъл) е трансформирането на данни от една форма в друга. За счетоводството картографирането е съставянето на таблица със съответствия на счетоводни сметки от различни сметкопланове, например руския сметкоплан и сметкоплана на GAAP (IFRS) (или сметкоплана на управленското счетоводство).

Пример 1. Смесена версия на организацията на комуникацията.

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

Отчитането се трансформира на най-малко четири етапа с помощта на таблици за картографиране и ръчни настройки.

1-ви етап.Структурна трансформация на баланса и отчета за приходите и разходите. Резултатът е прегрупиране и агрегиране на отделни елементи във финансовите отчети, за да се подготви база данни за последващи коригиращи записи. В същото време таблицата за съпоставяне съдържа показатели за финансово отчитане по RAS и тяхното отразяване в междинното отчитане по МСФО.

2-ри етап.Извършване на коригиращи записи, насочени към премахване на качествените разлики между руското отчитане и отчитането по МСФО. Извършва се ръчно от специалист по трансформация.

3-ти етап.Изготвяне на отчетност по МСФО на базата на трансформирани баланси, отчети за приходите и разходите и други форми. Таблицата за съпоставяне включва индикатори за междинно отчитане по МСФО и описание на корекциите, направени от специалиста по трансформация.

4-ти етап.Изготвяне на описателната част на доклада.

Таблица 1. Илюстрация на връзката между руския сметкоплан и сметкоплана на GAAP (екстракт)

Инвестиционен отдел (облагаем)

Investm. Заминаване (с приспадане)

Отдел за оценка

Valuat dept. (подлежи на приспадане)

Изследователски отдел (облагаем)

Изследователски отдел (подлежи на приспадане)

ДДС върху ДДС върху продажбите

ДДС - услуги

Минуси услуги ДДС

Общи приходи

Брутни продажби/приходи

Себестойност на продажбите

Investm. Заминаване (с приспадане)

Други начислени данъци (TsP)

Друго събиране на данъци

Търговски марж (отстъпка, наметка)

Търговската надбавка (отстъпка, надбавка)

Отстъпка от доставчика за възстановяване на транспортни разходи

Отстъпка на доставчиците за възстановяване на транспортни разходи

Продажба и продажба на дълготрайни активи

Разпореждане с дълготрайни активи

Продажба на други активи

Разпореждане с други активи

Основно производство

Основното производство

Спомагателно производство

Допълнителни продукции

Общопроизводствени разходи

Общопроизводствени разходи

Маркетингов отдел (облагаем)

Напускане на пазара (с приспадане)

Маркетингов отдел (необлагаеми)

Отклонение от пазара (неподлежащо на приспадане)

Продажби – основна дейност

Продажби/приходи – основна дейност

Себестойност на продажбите

Брутна печалба

Нетни продажби

Общи, търговски и административни разходи

Продажба на общи и административни разходи

Картографиращите таблици се използват и при генерирането на отчети за корпоративно управление (обикновено в холдингови компании и компании с клонове).

Основата за създаване на картографиране е групирането на счетоводните данни по определен начин (според фирмените стандарти).

Най-просто казано, когато създаваме корпоративен отчетен ред, ние посочваме точно кои обороти (или салда по сметки (подсметки)) и в какъв ред трябва да се използват автоматична системасчетоводство за формиране на този ред.

Картографирането е правилата, които сте заложили, според които ще се генерират нужните ви справки. Техническите принципи за генериране на картографски линии са еднакви за всички отчетни форми, разликата е само в съдържанието.

В тази връзка трябва да се отбележи, че картографирането трябва да бъде конфигурирано от квалифицирани специалисти и, което е важно, по единен методологичен начин. Процедурата по картографиране изисква много време.

Основата на управленското счетоводство (както и на счетоводството) са: сметкоплан, бюджетни позиции и различни аналитични справочници.

Управленският сметкоплан обаче се различава значително от стандартния сметкоплан, който се използва за счетоводство по счетоводство, тъй като някои от сметките на управленския сметкоплан (наричан по-долу MCA) може да имат по-подробни анализи и другата част може да има по-изчерпателна аналитика (всичко зависи от конкретните предприятия). Структурата на аналитичните справочници също е различна, тъй като докладите за управление изискват представяне на счетоводна информация в напълно различен контекст от този за счетоводните отчети.

Разбира се, на практика свързващите индикатори ( картографиране) управленско, данъчно и счетоводно (финансово) счетоводство създава много проблеми.
Нека разгледаме някои от тях.

1. Липса на аналитичност в работния сметкоплан (наричан по-долу ССП) на дружеството.

Това е разбираемо, тъй като предприятията, създадени за един ден, не винаги са имали дългосрочна стратегия и интересите на акционерите не винаги са били зачитани. Днес самата култура на бизнеса се е променила. Акционерите, включително държавата, проявяват все по-голям интерес към това колко компетентно и умело управляват предприятието мениджърите на всички нива.
Решението на този проблем е разширяване и допълване на съществуващата касова система на фирмата и постепенно натрупване на информация за нововъведени сметки (подсметки).

Разбирането на основните подходи за изграждане на сметкоплан, както и трите компонента (финансов, данъчен, управленски) на единната счетоводна система в една компания, предопределят необходимостта от подчертаване на три основни компонента в системния подход към финансово-счетоводната система на търговска организация, а именно:

  1. финансови (счетоводни);
  2. данък;
  3. управленски.

По-долу са представени възможните тълкувания на финансовите, данъчните и управленските компоненти на системния подход към RPS.

Финансов (счетоводен) компонент.Използването на RPS трябва да гарантира възможността за генериране на всички (без изключение) произтичащи счетоводни и аналитични показатели на външни финансови отчети и обяснителни бележки в контекста на сметките на Главната книга към отчетната дата. Блокът от счетоводни сметки на RPS, участващи във формирането на външни счетоводни отчети, са финансови сметки. От своя страна финансовите сметки се делят на аналитични и синтетични. Подсметки финансово счетоводство RPS са междинни между аналитични и синтетични. Освен това финансово-аналитични и синтетични сметки, както и подсметки, могат да представляват неразделна част от управленския компонент на RPS. Така например има данните, отразени в отделни подсметки на финансова сметка 90 „Продажби“. важноза вземане на управленски решения.

При формиране на група финансови сметки на RPS трябва да бъдат изпълнени следните изисквания:

  1. между външните счетоводни отчетни позиции и салдата по финансовите сметки трябва да се установи съответствие, което не изисква допълнителни логически операции за определяне на вида на отчетната позиция;
  2. минималният възможен набор от финансови сметки на RPS трябва да се формира целенасочено въз основа на състава на показателите за външно финансово отчитане;
  3. всеки индикатор за външно финансово отчитане трябва да бъде получен от финансови счетоводни данни с помощта на RPS без допълнително декодиране или корекции.

Данъчен компонент.Използването на RPS в счетоводната система осигурява възможност за изчисляване на данъчната основа и размера на печалбата за данъчни цели в съответствие с изискванията на гл. 25 Данъчен кодекс на Руската федерация. Прилагането на данъчния компонент на систематичния подход към RPS включва:

  1. организиране на аналитично финансово и данъчно счетоводство на разходите и приходите, за да се идентифицира тяхното влияние върху размера на данъчната основа за изчисляване на данъка върху печалбата на търговска организация чрез детайлизиране на финансовите сметки (01 - 99) RPS;
  2. разработване на списък с данъчни сметки (например 101–199). Тяхното внедряване ще позволи да се водят отчети за отклонения в счетоводните данни на финансово-данъчни счетоводни обекти с цел създаване на данъчно счетоводство и данъчна отчетност;
  3. разработване на правила, които позволяват да се коригира влиянието на данъчния компонент върху единната интегрирана счетоводна отчетност, за да се елиминира дублирането на отчетни (резултатни) счетоводни и аналитични показатели.

Компонент за управление. В RPS, за да се получат получените счетоводни и аналитични показатели на вътрешното управленско отчитане и управленското счетоводство, се разпределя блок от управленски сметки (например 201–299). В тези управленски сметки се правят корекции с двойно записване на финансови сметки 01–99 въз основа на изискванията на потребителите за вътрешно управленско отчитане. В бъдеще данните за управленските сметки 201–299, когато се използват определени правила, допълват (коригират) данните за финансовите сметки 01–99. Резултатът от тези действия са показатели за вътрешно управленско отчитане.

Прилагането на управленския аспект в системния подход към формирането на RPS включва разработването на:

  1. провизии счетоводна политика(външни и вътрешни), изясняване на критериите за признаване на счетоводни обекти, тяхната оценка, както и разкриване на съдържанието на елементите на управленската отчетност;
  2. подсистема от управленски сметки на единната РПС, необходима за записване и обобщаване на отклоненията на управленските счетоводни данни от финансовите счетоводни данни;
  3. алтернативен състав на финансовата отчетност на формите за отчетност на управлението.

Освен това, когато се формира блок от управленски сметки за RPS, е необходимо да се разработи таблица „Връзка (картографиране) между подсистемите на финансовите и управленските сметки с индикатори за алтернативно управленско отчитане.“

Таблица 2. Картографиране на руски счетоводни (финансови) счетоводни операции за генериране на редове на формуляра за корпоративна отчетност „Баланс“ (екстракт)

Дебитен оборот

ОС в организацията

OS групи:<все>

Инвестирани в нетекущи
активи

Не се променяйте

Дивизии:<все>

Без промени

Код на проекта:<все>

Не разгъвайте

Участва в груповата контрола с плюс

Фиксирани активи: Други дълготрайни активи

Строителни проекти (p): Вид на приходите от дълготрайни активи (Получаване от трети страни)

Дебитен оборот

ОС без регистрация

OS групи:<все>

Не се променяйте

Дивизии:<все>

Без промени

Код на проекта:<все>

Не разгъвайте

Участва в груповата контрола с плюс

Фиксирани активи: Други дълготрайни активи

Строителни проекти (p): Вид на приходите от дълготрайни активи (Получаване от трети страни)

Дебитен оборот

MC в организацията

Инвестирани в нетекущи активи

Не се променяйте

Без промени

Не разгъвайте

Участва в груповата контрола с плюс

Дълготраен(и) актив(и): Тип фиксиран доход (Получаване от трети страни)

Дебитен оборот

MC, отпред. във временно владение

Изпълнители:<все>

Инвестирани в нетекущи
активи

Не се променяйте

Споразумения:<все>

Без промени

Код на проекта:<все>

Не разгъвайте

Участва в груповата контрола с плюс

Фиксирани активи: Други дълготрайни активи

Строителни проекти (p): Тип разписка OS (получаване от трети страни)

Дебитен оборот

MC, отпред. за временно ползване

Изпълнители:<все>

Инвестирани в нетекущи
активи

Не се променяйте

Споразумения:<все>

Без промени

Код на проекта:<все>

Не разгъвайте

Участва в груповата контрола с плюс

Линия на баланса

Счетоводна сметка

Избор по подконто 1

кор. счетоводна сметка

Избор по подконто 1

Формула за избор

Избор чрез подконто 2

Избор чрез подконто 2

Обърнат знак

Избор чрез подконто 3

Избор чрез подконто 3

Счетоводство по ДДС

Избор чрез подконто 4

Избор чрез подконто 4

Разширете с

Избор чрез подконто 5

Избор чрез подконто 5

Участие в групов акаунт

BL00102 Пуснат в експлоатация (+)

Пуснат в експлоатация (+)

Пуснат в експлоатация (+)

Пуснат в експлоатация (+)

Пуснат в експлоатация (+)

Пуснат в експлоатация (+)

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

  • единен интегриран сметкоплан за финансово, данъчно и управленско счетоводство;
  • интегриран сметкоплан за финансово и данъчно счетоводство, автономен сметкоплан за управленско счетоводство;
  • интегриран сметкоплан за финансово и управленско счетоводство; автономен сметкоплан за данъчно счетоводство;
  • интегриран сметкоплан за данъчно и управленско счетоводство; автономен сметкоплан за финансово счетоводство;
  • автономни сметкопланове за финансово, данъчно и управленско счетоводство.

2. Проблеми на конструирането на справочници и класификатори, основните от които са:

  • дублиране на информация в справочници;
  • Неправилно кодиране на директории с термини.

Често се случва например, че няма единна процедура за присвояване на кодове и имена, един и същ контрагент може да бъде посочен в указателя два пъти (Romashka LLC и Romashka LLC, други опции и комбинации) или под различни имена (например под пълно и под съкращения). Търсенето на необходимите данни в информационна система чрез неструктурирани директории е доста сложно и неудобно. В допълнение, бъркотията в справочниците причинява грешки в отчитането.

Например, всяко предприятие, което е част от холдинга, до известна степен самостоятелно поддържа първични записи, разработва и актуализира свои собствени указатели. Тази работа в предприятията обикновено се извършва от различни служби: финансови отдели, маркетингов отдел, правен отдели т.н. Всичко това ви позволява да вземате оптимални управленски решения в рамките на конкретно предприятие. Въпреки това разбирането и възможността за анализ на текущото състояние на стопанството като цяло е много трудно поради неструктурирания и унифициран характер на информацията.

Друга често срещана ситуация: в една от компаниите, поради редовни заявки от маркетинговия отдел към счетоводния отдел относно структурата на продажбите, счетоводителите трябваше ръчно да събират информация в необходимите информационни секции. Това се дължи на факта, че отделът по продажбите не винаги въвежда в директорията данните, необходими за автоматичното генериране на необходимите отчети.

– Несъвместимост на части автоматизирана системасчетоводство.
Например отделът за доставки поддържа регистри и указатели на ITC в програмата Cache, а счетоводни (финансови) и управленски регистри и указатели се поддържат в SAP R3, като там се генерира и фирмена отчетност. Форматите за представяне на данни в тези програми са различни, така че конвертирането на данни между тях е трудно, а в някои случаи директно невъзможно.

При разработването на справочници трябва да се спазват следните принципи.

– Детайлите и структурата на директориите трябва да са такива, че да е възможно бързо да се обработват данни и да се генерират необходимите отчети.

Ако справочникът не е достатъчно подробен, това ще затрудни получаването на необходимата информация. Например, ако в средата на годината трябва да знаете за производствените разходи рекламни брошурипо поръчка на маркетинговия отдел и преди това всички маркетингови разходи бяха взети предвид заедно, тогава ще е необходимо да се направи допълнителен подбор на информация въз основа на косвени показатели (например от печатници). (За холдинги или групи от компании детайлността на указателите ще зависи от изискванията за структуриране на информацията не само на отделно предприятие, но и на целия холдинг.)

Ако справочникът е много подробен, тогава е трудно да го напълните с информация и да го използвате в работата си. Например директорията „Паричен поток“ може да съдържа повече от хиляда различни целиплащане. Изготвяне на отчет за паричните потоци за основни плащания за генерален директорще отнеме много време, тъй като ще трябва да извършите необходимото групиране (обединяване на индикатори или избор на необходимата информация от масив от излишна информация). Освен това, когато въвежда информация, потребителят може да не знае къде да включи конкретно плащане. Това неизбежно ще доведе до неправилен избор на артикули от указателя или класифициране на плащането като „друго“. Препоръчително е да се опише подробно кои счетоводни обекти могат да бъдат отразени за всеки ред от справочника.

– Кодирането на елементите на директорията трябва да елиминира дублирането на информация и да помогне за ускоряване на работата с директорията. Преди кодиране на данни е необходимо да се определи в коя от корпоративните информационни системи ще се съхраняват справочните директории. Възможността за използване на определени кодове до голяма степен ще зависи от възможностите на системата. Такава система може да бъде счетоводна програма, информацията от която автоматично се прехвърля към други системи, които използват същите директории.

– Трябва да избягвате използването на подобни кодировки в различни директории.
Например, ако при анализ на продажбите маркетинговият отдел идентифицира групите купувачи не по регион, а по град и регион, тогава групите за анализ не трябва да съвпадат с кодовете на федералните региони. В противен случай това ще доведе до грешки при въвеждане на информация. По този начин кодът „77“ е зададен за Москва, а Белгородската област е посочена под този код в предприятието. В резултат на това служителят може да припише определен типпродажби не в региона, а в Москва и информацията ще бъде изкривена. В този случай се препоръчва да се създават кодове с различна дължина, например за кодиране на маркетингови групи, използвайте три цифри (код „770“ за клиенти в региона на Белгород);

– В идеалния случайКодът на указателя не трябва да надвишава 8 знака. В противен случай данните се въвеждат трудно, тъй като кодовете не се различават лесно един от друг.

– при създаване на взаимосвързани директории трябва да се елиминира дублирането. За да се избегнат грешки в указателите (поради несистематичния и хаотичен характер на попълването им), е необходимо да се анализира информацията, съдържаща се в тях, за да се идентифицират данните, които могат да бъдат генерирани от отделни указатели.

– Разработвайки единна системадиректории, е необходимо да се осигури защитата му от неоторизирани промени. Достатъчно висока сигурност обикновено може да се постигне както чрез използване на методи за идентификация на потребителите, така и чрез разграничаване на правата за достъп на потребителите до информация. Най-често за създаване и поддържане на директории компаниите разработват регламенти, които определят лицата, отговорни за въвеждането на информация в директории и нейната промяна.

В заключение трябва да се каже, че е необходимо да се решат горните проблеми, преди да се създаде картографиране. В противен случай едва ли можете да разчитате на генериране на управленски отчети. Дори ако отчетът е генериран, вероятността той да е правилен е практически нулев. Причините са очевидни:

  1. Грешки, които ще се появят поради описани по-рано проблеми.
  2. Счетоводни грешки (както методически, така и счетоводни). Хората водят записи, не забравяйте това.
  3. След това трябва да дадем дълъг списък от различни видове грешки, чийто източник ще бъдат резултатите от наслагването на параграфи 1 и 2. Според нас обаче това не е необходимо.

Компаниите, които използват Excel за целите на трансформацията на отчетите, получават осезаеми спестявания при изготвянето на финансови отчети по МСФО. Ако обемите на транзакциите позволяват идентификационните данни да бъдат обработвани в електронни таблици, препоръчително е да използвате Excel

12.01.2016

Таблиците на Excel, в допълнение към аритметичната точност и яснотата на процедурите за трансформация, ви позволяват да генерирате данни за икономически анализфинансови дейности, базирани на резултатите от МСФО, което превръща отчетния модел в инструмент за управление.

Подготвителен етап на трансформация на отчета

включено подготвителен етапизвършва се анализ на специфичните разлики между МСФО, приложими за дадена компания, и счетоводните практики по RAS. Трябва да се отбележи, че е неуместно да се изхожда от правилата на руското счетоводство, тъй като в този случай ще бъде трудно да се избяга от „приоритета на формата над съдържанието“ - трябва да започнете с анализ на компанията като цяло и дейността си от гледна точка на МСФО.

Международните стандарти, приложими за всеки конкретен бизнес, трябва да бъдат включени в счетоводната политика по МСФО. Например, търговско предприятие е малко вероятно да използва сложни финансови инструменти или разпоредбите на МСС 41 Земеделие, а от частна компания не се изисква да оповестява печалба на акция съгласно МСС 33 Печалба на акция. Процедурата за разработване на счетоводна политика трябва да бъде насочена не само към създаване на счетоводни правила и меморандуми в съответствие с МСФО, но и към изготвяне на блок от бележки директно към отчетите по МСФО, съдържащ основните аспекти на счетоводната политика, които трябва да бъдат оповестени в в съответствие с МСС 1 „Представяне на финансови отчети“.

Въз основа на получените счетоводни политики по МСФО е необходимо да се идентифицират несъответствията в оценките и принципите, използвани в RAS и да се създаде списък и правила за изчисляване на основните корекции на трансформация, както и списък на допълнителна информация, необходима за целите на МСФО, но не се вземат предвид в съответствие с изискванията на руското законодателство.

Когато прилагате международни стандарти за първи път в съответствие с МСФО 1, трябва да сте наясно с изключенията и опростяванията, разрешени от стандарта, и че тези облекчения вече не се прилагат.

Процесът на актуализиране на счетоводната политика по МСФО, списъкът с корекции и списъкът с допълнителна информация трябва да бъде постоянен, тъй като изискванията на МСФО и руското законодателство непрекъснато се актуализират.

Съпоставяне на сметкоплан за трансформация на отчитане

Картографиране - от английското картографиране (кореспонденция, както и трансформация) - е процедура за публикуване на данни в няколко координатни системи, в нашия случай преобразуване на салда и оборот, генерирани в съответствие със сметкоплана на RAS, в структурата на диаграмата на сметки по МСФО (Таблица 1).

Таблица 1. Пример за картографиране на сметкоплана

Няколко думи за изготвянето на действителния сметкоплан според МСФО.

  • Всеки индикатор по МСФО трябва да има уникален цифров код, в краен случай буквено-цифров, в строго определен формат. Сумиране на показателите в съвр Версии на Excelвъзможно е дори въз основа на характеристиките на текста, но в този случай рискът от изкривяване на данните в случай на обикновена печатна грешка се увеличава. За минимизиране на грешките се използват директории и падащи списъци с кодове и имена на сметки и анализи, както и формули “SUMMIF” и “VLOOKUP”, които обобщават данни с определени характеристики, а именно уникални кодове.
  • Йерархията на сметкоплана трябва да ви позволява да групирате данни не само по елементи, но и по редове на отчетната форма и бележки. Да кажем, че статията „Сгради и конструкции - Първоначална цена“, в допълнение към собствения си код, трябва да съдържа сред анализите и код на ред за отчета за финансовото състояние (наричан по-нататък баланс) и код на таблица с бележки , което ще ви позволи да попълвате формуляри и таблични отчетни бележки с помощта на формули на Excel.
  • Всеки раздел на отчетните форми в сметкоплана трябва да съдържа резерв празни редове- това дава възможност за гъвкаво коригиране на сметкоплана без преконфигуриране на формули, а също така ви позволява да не нарушавате принципа на съпоставимост на данните. Препоръчително е да се предвиди място за нови секции, например, ако компанията не е притежавала преди това инвестиционен имот, но ръководството планира да създаде или придобие недвижим имот за отдаване под наем. В този случай просто попълвате празните редове и въвеждате кодове за отчитане, а Excel автоматично агрегира индикаторите.
  • Необходимо е да се запази историята на промените в картографирането (обикновено въз основа на меморандум или друг административен методически документ), като се посочи причината, отговорното лице и времето на влизане в сила на промените. Това е важно както за генериране на сравними данни от период на период, така и за преминаване на одит.

Трябва да се отбележи, че колкото повече анализаторът съдържа руския сметкоплан, толкова по-лесно е да извърши корекциите за картографиране и прекласификация, необходими във връзка с различни принципиагрегиране на данни в RAS и IFRS. Ето защо, ако е възможно, сметкопланът RAS и неговите анализи трябва да бъдат възможно най-близо до нуждите на МСФО, за да се повиши ефективността на процеса на трансформация и да се намалят разходите.

Събиране на необходимата информация за попълване на трансформационния модел.На този етап се събират данни за салдата по балансовите сметки и оборота на сметките за приходи и разходи за отчетния период, попълват се началният баланс и отчетът за приходите и разходите.

Заедно с този процес се преглеждат значителни транзакции, съдебни спорове, големи нови договори и допълнителни оповестявания. Да се ​​разработи регламентиран списък с допълнителна информация, както и да се определят отговорници за изготвянето на съответните данни и да се определят срокове.

Списъкът, представен в таблица 2, може да бъде съкратен, ако компанията няма определени операции, или значително разширен. По правило рядко се случват промени в дейността на компанията, които водят до допълнителни корекции на МСФО. Затова най-задълбоченият анализ се прави при първоначалното запознаване с бизнеса и едва след това се следят съществените промени. Така в повечето случаи компаниите трябва да направят около десет до двадесет трансформационни корекции, които могат да бъдат регулирани чрез подходящи методически указанияи са заложени в документа „Процедура за отчитане на корекциите за трансформация“.

Таблица 2. Примерен списък с допълнителна информация

Всички корекции трябва да бъдат направени под формата на работен документ, подобен на счетоводен отчет. Работният документ трябва да съдържа методическа основаи действителните предпоставки, въз основа на които са направени определени корекции, и самите изчисления. Необходимо е също така да се установят процедури за контрол, насочени към проверка на коректността на изчисленията, съгласуване на данни от работни документи и модели на трансформация, както и коректността на транзакциите.

Етап на формиране на входящи корекции. Входящите корекции се генерират при първото прилагане на МСФО, както и при транзакции, включващи придобиване на нови компании, които трябва да бъдат оценени по справедлива стойност.

Като начало позициите в баланса и отчета за приходите и разходите се прегрупират. Това са така наречените корекции за прекласифициране. Основните корекции на прекласификация включват сторниране или сторниране на вземания, задължения и аванси, прекласификация на отсрочени разходи, разделяне на текущи и нетекущи активи и пасиви, прехвърляне на депозити с падеж под 90 дни в брой и по-подробно осчетоводяване на приходи и разходи в свързани сметки, ако такава работа не е извършена на етапа на картографиране (Таблица 3).

Таблица 3. Пример за таблица за прекласификация

Следващият блок от корекции са корекции, които засягат сумата на позициите в баланса, както и приходите и разходите. Те не трябва да се бъркат с корекциите за прекласифициране, тъй като само приблизителните корекции влияят върху размера на отсрочените данъци съгласно МСФО.

На практика най-значимите корекционни суми са свързани с оценката на активи по справедлива стойност – дълготрайни активи (особено в случаите, когато дружеството притежава стари активи) и нематериални активи. Невъзможно е да изчислите такива корекции сами, тъй като това изисква данни от доклад от проверка, извършена от квалифициран оценител. Например без специални знанияи опит е невъзможно да се определи цената клиентска база, който при закупуване на компания трябва да бъде признат като нематериален актив по МСФО. Само след получаване на данни за оценка на справедливата сума на първоначалната цена, степен на амортизация, оставаща полезен животизползване, регистрите на дълготрайните активи и нематериалните активи се формират съгласно МСФО. Счетоводното отчитане на дълготрайните активи и нематериалните активи може да се извършва както в отделна програма, а в електронни таблици, когато се поддържа регистър на дълготрайните активи в Excel, се отразяват постъпления, модернизации, изхвърляния на обекти, амортизацията се изчислява по себестойността, призната в съответствие с МСФО.

Най-простият начин за изчисляване на корекциите е да се сравнят данните по RAS и IFRS и да се определи несъответствието между тях. Тези суми формират изменението (Таблица 4).

Таблица 4. Изчисляване на корекции за преоценка на дълготрайни активи по справедлива стойност

В допълнение към отразяването на преоценката, за дълготрайни активи и нематериални активи може да се наложи преизчисляване на размера на капитализираната лихва, тъй като RAS и IFRS съдържат различни подходи за определяне на размера на капитализацията.

Разпоредбите на МСС 36 Обезценка на активи също се фокусират повече върху тестването на имоти, машини и съоръжения и нематериални активи, чиято стойност трябва да се коригира, когато има доказателства за обезценка.

Ако дадено дружество използва финансов лизинг в дейността си (съгласно тълкуването на МСФО), промените могат също да засегнат размера на имотите, машините и оборудването и разходите за амортизация, в съответствие със задълженията по финансов лизинг и вземанията за лихви за използване на заемни средства.

Особено внимание трябва да се обърне на корекциите, свързани с дисконтирането (както например в случай на дългосрочен финансов лизинг, когато както цената на дълготрайните активи, така и дългът по договори за финансов лизинг се оценяват на базата на дисконтиране). МСФО изискват дисконтиране на всички дългосрочни активи и пасиви:

  • размера на приходите, когато плащането е отложено във времето;
  • сумата на дългосрочен резерв или провизия в съответствие с МСС 37 „Провизии, условни пасиви и условни активи“;
  • разходите за инвестиране в дъщерно дружество, когато е предвидено разсрочено плащане на акции;
  • дългови компоненти на дългосрочни конвертируеми облигации;
  • възстановимата стойност на финансов актив, отчетен по амортизирана стойност при тестване за обезценка и др.

Сред най-често срещаните корекции можем също да отбележим:

  • за материални запаси (отписване на неликвидни материални запаси като загуби, създаване на резерв за амортизация на материални запаси, отписване като разходи на липси и загуби от щети на ценности, както и някои видове разходи за бъдещи периоди);
  • за разчети с персонал (корекции на резерви за отпуски, създаване на резерв за бъдещи възнаграждения, разчети по пенсионни планове);
  • Корекции на прекъсване (отписване на отсрочени приходи, допълнително начисляване или отписване на приходи и разходи за отчетния период, които не са отразени в RAS поради липса на документи или различия в подхода за признаване на момента на прехвърляне на рискове и ползи, в кореспонденция със сметки за сетълменти с контрагенти);
  • за вземания и задължения, както и заеми и заеми (отразяване по амортизирана стойност с помощта на метода на ефективната лихва, корекция на резервите за съмнителни дългове);
  • относно финансови инвестиции (признаване на дял в печалбата или загубата на асоциирани дружества, корекции на стойността на финансовите инвестиции, чрез които може да се определи текущата пазарна стойност и др.).

След като бъдат генерирани всички прогнозни корекции, се определя сумата на корекцията на отсрочения данък върху дохода.

Разбира се, не са изброени всички възможни корекции, тъй като целта е да се демонстрира как се формира групата от входящи корекции и как корекциите трябва да се пренасят от година на година (Таблица 5).

Таблица 5. Формиране на списък с входящи корекции

След това, като се вземат предвид входящите корекции, се изготвят балансът, отчетът за печалбата и загубата, отчетът за промените в капитала, отчетът за паричните потоци във формат МСФО, както и обяснения към отчетите.

Първичните корекции се използват за пренасяне в отчитането на следващи периоди като входящи корекции. Има два метода за прехвърляне:

  • корекциите на балансовите сметки се вземат предвид в съответствие със сметката на неразпределената печалба;
  • корекциите на сметките за приходи/разходи се сторнират в съответствие със сметката за неразпределена печалба.

Изборът на метод на прехвърляне засяга само техниката за изчисляване на текущите корекции за следващите отчетни периоди, но вече няма да е възможно да промените модела за изчисляване на корекциите, така че трябва да определите предварително най-много; удобен метод и се придържайте към него.

Етап на формиране на корекции за следващи отчетни периоди. Типичните корекции през следващите отчетни периоди трябва да бъдат изготвени, като се вземат предвид входящите корекции. Механизмът за генериране на данни по МСФО е както следва: Excel таблиципопълнено страница по страница:

  • картографиране на салда и обороти по RAS в салда и обороти по МСФО;
  • корекции при прекласифициране;
  • входящи корекции (с изключение на прекласирания от предходния период);
  • корекции за текущия период (изчислени в отделни работни документи, като се вземат предвид натрупаните входящи корекции).

След това, използвайки формулите „SUMIF“, данните се изтеглят нагоре в обобщения лист (вижте таблица 6).

Таблица 6. Формиране на данни по МСФО в трансформационния модел

Данните по МСФО (колона 8) се получават чрез сумиране на оригиналните данни по RAS, прекласификации, входящи и текущи корекции. На следващия етап, също използвайки формулата „SUMMIF“, готовите индикатори по МСФО се агрегират на страниците на отчета (баланс, отчет за печалбите и загубите) по редови кодове на формуляри за отчет в съответствие с присвоения код на формуляр за отчет (Таблица 7) . По същия начин се попълват таблични форми на бележки, формули за контрол и равнение се записват между таблицата за трансформация, отчетни формуляри и бележки и промяната в неразпределената печалба за периода се сравнява с началните и крайните салда за показателя ( възможни са несъответствия в размера на начислените дивиденти).

Таблица 7. Пример за използване на функцията „SUMIF“ на Excel

Както виждаме, Excel ви позволява съвсем просто и ясно да генерирате МСФО данни чрез трансформация. На практика се използват и други подходи за попълване на таблици за трансформация, например като класически шах. Ако обаче има много корекции, получените файлове ще бъдат обемисти и рискът ще се увеличи. технически грешкиОсвен това става трудно да се анализират измененията, натрупани за няколко периода. Какъвто и модел на трансформация да се използва, има универсални препоръки за работа с Excel: данните трябва да се съхраняват на надеждни сървъри, защитени от неоторизиран достъп, автоматично създаване на резервни копия на основните работни файлове и автоматично запазване по време на работа, редовно архивиране на двете основни данни и крайни модели, проследяване на промените във файловете и поддържане на файл с обобщен статус (чеклист), съдържащ информация за необходимите етапи на трансформация и степента на изпълнение на установените процедури.

Скъпи приятели!

Днес имаме удоволствието да ви информираме, че нашите разработчици са внедрили възможността за транспортиране на данни чрез URL (картографиране) извън целевата страница.

С помощта на тази функция можете да прехвърлите всички данни от полетата на формуляра към страницата, на която потребителят отива, когато ви изпраща потенциален клиент. Благодарение на това потенциалният клиент не само попада в , но може веднага да влезе във вашата база данни, ако бъде „срещнат“ от съответния скрипт на страницата за пренасочване.

Вече няма нужда да експортирате данни от системата за обработка на потенциални клиенти! Можете да ги изпращате и обработвате незабавно в собствената си база данни!

Освен това, благодарение на тази функция, става възможно лично да поздравите или благодарите на потребителя, който е предоставил своята информация за контакт.

Как работи картографирането?

Същността на картографирането е, че при изпращане на данни от полетата на формуляра, тяхното съдържание се добавя към връзката, към която се извършва пренасочването. URL адресът става: //my_site.com/?name=NAME&email=EMAIL_ADDRESS&phone=PHONE_NUMBER&lead_id=225298.

важно! В допълнение към всички данни на полето, идентификаторът на потенциален клиент винаги се предава в параметъра lead_id.

На страницата, към която се извършва преходът, тази информация се „получава“ от специален скрипт, който от своя страна разпределя данните в съответните „клетки“.

Моля, обърнете внимание! Картографирането работи само ако „Резултатът от формуляра“ е „Отидете на URL“!

Как мога да настроя „транспортиране“ на потенциален клиент чрез URL (съпоставяне) на моята целева страница?

1. Влезте.
2. Изберете страницата с водещата форма, от която ще „излъчвате“ данни.

3. В редактора направете щракнете двукратноспоред формата.

4. В прозореца, който се показва, попълнете колоната „Mapping“ със съответните имена на полета на английски език. Например име - име, телефон - телефон и т.н.

5. Запазете промените си.

6. В свойствата на формуляра конфигурирайте пренасочването към желаната страница- това може да е страница от вашия уебсайт, в която е вграден JavaScript, който ще обработва данните от полетата, получени от URL адреса.

Поставете отметка в квадратчето „Подаване на полета на формуляр“.

7. Запазете промените в главното меню на редактора.

това е! :-)

Сега данните от вашите полета на формуляра ще бъдат прехвърлени към страницата, към която пренасочвате потребителя. Не е нужно да експортирате потенциални клиенти от CRM LPgenerator - те могат да бъдат „транспортирани“ към вашия CRM директно чрез URL. Възможностите за картографиране за транспортиране на данни са наистина неограничени.