Generarea rapoartelor companiei folosind cartografiere. Ce este maparea portului
Dragi prieteni!
Astăzi suntem încântați să vă informăm că dezvoltatorii noștri au implementat capacitatea de a transporta date prin URL (mapping) dincolo de pagina țintă.
Folosind această funcție, puteți transfera toate datele din câmpurile formularului pe pagina la care merge utilizatorul atunci când vă trimite un client potențial. Datorită acestui fapt, liderul nu numai că intră în , ci poate intra imediat în baza ta de date dacă este „întâlnit” de scriptul corespunzător de pe pagina de redirecționare.
Acum nu mai este nevoie să exportați date din sistemul de procesare a lead-urilor! Le poți trimite și procesa imediat în propria ta bază de date!
De asemenea, datorită acestei funcții, devine posibilă felicitarea sau mulțumirea utilizatorului care a furnizat personal informațiile sale de contact.
Cum funcționează cartografierea?
Esența mapării este că atunci când se trimit date din câmpurile de formular, conținutul acestora este adăugat la linkul către care are loc redirecționarea. Adresa URL devine: //my_site.com/?name=NAME&email=EMAIL_ADDRESS&phone=PHONE_NUMBER&lead_id=225298.
Important! Pe lângă toate datele câmpului, ID-ul clientului potențial este întotdeauna transmis în parametrul lead_id.
Pe pagina către care se face tranziția, aceste informații sunt „primite” de un script special, care, la rândul său, distribuie datele în „celulele” corespunzătoare.
Atrageți-vă atenția asupra! Maparea funcționează numai dacă „Rezultatul formularului” este „Mergeți la URL”!
Cum pot configura „transportul” unui client potențial după adresa URL (mapping) pe pagina mea de destinație?
1. Conectați-vă.
2. Selectați pagina cu formularul de prospect din care urmează să „difuzați” datele.
3. În editor, faceți dublu clic pe formular.
4. În fereastra care apare, completați coloana „Mapping” cu numele câmpurilor corespunzătoare activate Limba engleză. De exemplu, nume - nume, telefon - telefon etc.
5. Salvați modificările.
6. În proprietățile formularului, configurați redirecționarea către pagina dorită- aceasta ar putea fi o pagină a site-ului dvs. în care este încorporat JavaScript, care va procesa datele din câmpurile primite de la adresa URL.
Bifați caseta de selectare „Pass form fields”.
7. Salvați modificările în meniul principal al editorului.
Asta e tot! :-)
Acum datele din câmpurile formularului dumneavoastră vor fi transferate către pagina către care redirecționați utilizatorul. Nu trebuie să exportați clienții potențiali din CRM LPgenerator - acestea pot fi „transportate” în CRM-ul dvs. direct prin URL. Posibilitățile de cartografiere pentru transportul datelor sunt cu adevărat nelimitate.
Ai auzit de cartografiere? În transcrierea rusă este mapping, mapping. Conceptul are mai multe semnificații care nu sunt legate între ele. Să ne uităm la fiecare dintre ele în contextul zonei în care sunt relevante.
Ce înseamnă conceptul în general?
Mapping, mapping, mapping, mapping este determinarea corespondenței informațiilor dintre două semantici diferite ale unui obiect sau mai multor. Cu alte cuvinte, acesta este numele pentru conversia datelor dintr-un formular în altul.
Ce este cartografierea? În sensul său general, termenul este destul de larg - poate fi fie o transformare scrupuloasă a unei secvențe de elemente în alta, fie o conversie obișnuită a monedei sau a fișierelor. Astfel, tot ceea ce este ascuns sub termenul analizat este cel mai bine exprimat de conceptul de mapare a datelor în limba engleză.
Exemple de cartografiere
Să ne uităm la ce este maparea folosind următoarele exemple:
- Întocmirea unui document de corespondență a conturilor contabile din diferitele planuri ale acestora. De exemplu, rusă, IFRS, contabilitate de gestiune etc.
- Traducerea codurilor bazei de date de la un sistem la altul. De exemplu, trebuie să convertim denumirile 0 și 1 în „nu” și „da”.
- Conversia dolarilor în euro este un fel de mapare.
- Schimbarea formatului unei imagini de la .png la .jpg, un film de la .avi la .mp4, realizată într-un editor grafic sau video, se va raporta într-un fel la subiectul conversației noastre.
Dezvoltare de jocuri pe calculator
Mapping (din engleză. Hartă- „harta terenului”) poate fi folosită și în sensul designului de nivel. Acesta este numele dat disciplinei de dezvoltare a jocurilor video. Aceasta este, în primul rând, crearea unor niveluri de complexitate diferită - elaborarea misiunii jucătorului, designul locației, compunerea sarcinilor etc. În practică, astfel de activități se desfășoară în editorul de „niveluri”.
Tehnologiile de cartografiere aici sunt eterogene - totul depinde de bugetul dezvoltatorilor, de natura și de genul jocului creat. Să ne uităm la un exemplu clasic pentru a înțelege mai bine conceptul:
- Crearea unei hărți a teritoriului și împărțirea acesteia în zone - orașe, lanțuri muntoase, tuneluri subterane, păduri etc.
- Definirea regiunilor asociate cu o anumită activitate specifică a jucătorului - un câmp de luptă, un magazin pentru atribute suplimentare, extragerea resurselor, fortificații, un loc de odihnă, o tablă de onoare etc.
- Dezvoltarea obiectelor non-statice. Pot fi chei, uși, butoane și pasaje secrete, pasaje secrete care dispar etc.
- Determinarea locațiilor importante ale organizațiilor - acesta este un punct de recuperare, comori, comori, cache-uri cu arme secrete etc.
- Stabilirea locației de început și de sfârșit a mișcărilor pentru fiecare jucător.
- Aducerea hărții la viață cu o serie de detalii: adăugarea de elemente precum texturi, sunete, sunet, efecte vizuale, iluzii, animații etc.
- Inserarea declanșatoarelor necesare (mecanisme care verifică prezența oricărui obiect în spațiul de joc creat) și script-uri (scenarii, algoritmi scurti de acțiuni).
- Crearea anumitor scripturi pentru mișcarea mafioților (obiecte nestatice, personaje): zone în care se pot deplasa, interacțiunea lor, dialog cu jucătorul etc.
- Uneori include crearea de scene tăiate - frumos screensaver, un mini-film, un fel de trailer pentru un joc sau nivel, un grup de „niveluri” pe care un jucător nu poate decât să le vadă, dar nu influențează în niciun fel ceea ce se întâmplă în el.
Cartografiere video
Ce este maparea video (mapping 3D)? Aceasta este o tehnologie uimitoare care vă permite să proiectați imagini, filme special create pe suprafețe neuniforme la scară mare, de exemplu, pe fațadele clădirilor.
Unicitatea acestui lucru este că vă permite să „reînvie” casele și alte obiecte de interior oferindu-le mobilitate vizuală. Și totul se realizează doar prin proiectoare instalate după un anumit plan. „Magia” imaginilor tridimensionale în mișcare constă în corespondența super-preciză dintre elementele pe care se reflectă imaginea și proiecția video în sine.
Deși pentru mulți dintre noi cartografierea este o direcție destul de nouă, ea a luat naștere în anii șaizeci ai secolului trecut. Îi datorăm aspectul lui Walt Disney și studioului Disney. Apoi, numele de funcționare al cartografierii a fost „lămpi de umbrire”, „spațiu de realitate virtuală”. Primul spectacol este considerat a fi atracția Haunted Manor de la Disneyland. Pentru el s-au creat capete tăiate artificiale, pe care a fost proiectată o imagine, „revitalizandu-le”.
Cum poate fi maparea video?
În funcție de obiectul pe care se reflectă imaginea, tehnologia este împărțită în mai multe zone:
- Arhitectural. Proiecție volumetrică pe obiect complex- fațada unei clădiri, pod, turn, precum și a unui avion, navă etc.
- Interior. Crearea de soluții iluzorii interesante în interior prin proiectarea imaginilor pe pereți, tavan, podea.
- Pentru obiecte mici. Sunt folosite atât forme mici, cât și elemente ale ceva mai mare. De exemplu, roți de mașină, tort, rochie de mireasă etc.
- Amenajarea teritoriului. Baza sunt pădurile, munții și alte obiecte naturale.
- Interactiv. Cea mai nouă direcție tema excelenta că aici o persoană devine un erou. Tehnologia aduce la viață obiectele din jurul artistului, ajutându-l să creeze un spectacol de neuitat.
Unde se utilizează cartografierea 3D?
Să vedem unde poate fi relevantă această tehnologie:
- crearea de volum pe diferite suprafețe;
- sărbători ale orașului, evenimente publice;
- evenimente corporative majore;
- descoperiri centre de cumparaturi, complexe de divertisment;
- vacante pentru copii;
- evenimente culturale, istorice, educative.
Acest spectacol arată cel mai impresionant în întuneric. Pentru a da un efect mai izbitor, organizatorii îl combină cu sunet surround adecvat, muzică live, artificii.
Dacă doriți să faceți cunoștință cu recenzii ale tehnologiei, atunci ascultați-i pe cei care au vizitat cel puțin o dată Cercul de lumină din Moscova. De recent, în fiecare an în toamnă se desfășoară acest festival în capitală, atrăgând mii de spectatori. Designerii din diferite țări creează proiecții video care sunt afișate pe fațadă Teatrul Bolșoi, pavilionul principal al VDNH, clădirea principală a Universității de Stat din Moscova etc.
Cartografierea este un concept cu mai multe valori. Aceasta include conversia complexă a datelor, crearea de locații în jocurile pe calculator și un spectacol bazat pe proiectarea imaginilor pe obiecte de dimensiuni mari și mici.
În partea anterioară, am analizat tipurile de relații (unu-la-unu, unu-la-mulți, mulți-la-mulți), precum și o clasă Book și clasa sa de mapare BookMap. În a doua parte, vom actualiza clasa Book, vom crea clasele rămase și conexiunile între ele, așa cum a fost descris în capitolul anterior din Diagrama bazei de date situată deasupra subtitlului 1.3.1 Relații.
Codul claselor și mapărilor (Cu comentarii)
Cartea de clasă
Public class Book ( //Identificator unic public virtual int Id ( get; set; ) // Titlu public virtual string Nume ( get; set; ) // Descriere public virtual string Descriere ( get; set; ) // Rating of the World of Fiction public virtual int MfRaiting ( get; set; ) //Numere de pagină public virtual int PageNumber ( get; set; ) //Link către imagine public virtual string Image (get; set; ) //Data sosirii cărții (filtru) prin elemente noi!) public virtual DateTime IncomeDate ( get; set; ) //Gen (Many-to-Many) //De ce ISet și nu IList? Numai o colecție (IList) poate fi selectată folosind JOIN fetch, dacă aveți nevoie de mai multe decât o colecție pentru JOIN fetch, atunci este mai bine să le convertiți într-o colecție ISet virtuală publică ISet
Public class Author ( public virtual int Id ( get; set; ) //Nume-Prenume public virtual string Nume (get; set; ) //Biography public virtual string Biography ( get; set; ) //Books public virtual ISet
Genul clasei
Clasa publică Gen ( public virtual int Id ( get; set; ) //Numele genului public virtual string Nume (get; set; ) //Numele în engleză al genului public virtual string EngName (get; set; ) //Cărți ISet virtual public
Opinie de clasă:
Public class Mind ( public virtual int Id ( get; set; ) //My opinion public virtual string MyMind ( get; set; ) //opinia lui Fantlab public virtual string MindFantLab ( get; set; ) //Book public virtual Book Book ( obține; setează; ) ) //Mapping Mind clasă publică MindMap:ClassMap
Ciclu de clasă (serie):
Clasa publică Series ( public virtual int Id ( get; set; ) public virtual string Name ( get; set; ) //Am creat un IList, nu un ISet, deoarece, în afară de Book, Series nu este asociat cu nimic altceva, deși tu poate face și ISset public virtual IList
O mica explicatie
ISet virtual public
ISet virtual public
De ce ISet
Nu se pot prelua simultan mai multe pungi.
În astfel de cazuri, folosim ISet, mai ales că seturile sunt destinate pentru aceasta (ele ignoră înregistrările duplicate).
Relație de la mulți la mulți.
NHibernate are conceptul de tabel „principal”. Deși relația multi-la-mulți dintre tabelele Carte și Autor este echivalentă (Un autor poate avea multe cărți, o carte poate avea mulți autori), Nhibernate solicită programatorului să specifice tabelul care este stocat al doilea (are o metodă. invers ()), adică mai întâi se va crea/actualiza/șterge o înregistrare în tabelul Book, și abia apoi în tabelul Autor.
Cascade.All înseamnă efectuarea de operațiuni în cascadă la salvare-actualizare și ștergere. Adică, atunci când un obiect este salvat, actualizat sau șters, toate obiectele dependente sunt verificate și create/actualizate/adăugate (Ps. Poate fi scris în loc de Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Method.Table("Carte_Autor"); creează un tabel „intermediar” „Carte_Autor” în baza de date.
Relație multi-la-unu, unu-la-mulți.
Metoda.Constrained() îi spune lui NHibernate că o înregistrare din tabelul Book trebuie să se potrivească cu o înregistrare din tabelul Mind (id-ul tabelului Mind trebuie să fie egal cu id-ul tabelului Book)
Dacă acum rulați proiectul și vă uitați la baza de date Bibilioteca, vor apărea noi tabele cu conexiuni deja formate.
Apoi, completați tabelele create cu date...
Pentru a face acest lucru, vom crea o aplicație de testare care va salva datele în baza de date, o va actualiza și va șterge, schimbând HomeController-ul după cum urmează (comentăm secțiunile inutile ale codului):
public ActionResult Index() (folosind (sesiune ISession = NHibernateHelper.OpenSession()) (folosind (iTransaction tranzacție = session.BeginTransaction()) ( //Creați, adăugați var createBook = carte nouă(); createBook.Name = "Metro2033" ; createBook.Description = „Misticism post-apocaliptic”; createBook.Authors.Add(autor nou (Nume = „Glukhovsky”)); createBook.Genres.Add(gen nou (Nume = „Misticism post-apocaliptic” )); createBook .Series = serie nouă ( Nume = „Metro” ); createBook.Mind = nouă minte ( MyMind = „Misticism post-apocaliptic” ); session.SaveOrUpdate(createBook); //Actualizare (După ID) //var series = sesiune .Obține
O mica explicatie
- var books = session.QueryOver
() Selectați * Din carte; - .JoinAlias(p => p.Genuri, () => genreAl, JoinType.LeftOuterJoin)- similar cu executarea unui script SQL:
SELECTAȚI *DIN Carte
interior JOIN Book_Genre ON book.id = Book_Genre.Book_id
LEFT JOIN Gen ACTIVAT Book_Genre.Genre_id = Genre.id - .TransformUsing(Transformers.DistinctRootEntity)- Similar cu executarea unui script SQL: SELECTează carte. Id. distinctă..., (elimină înregistrările duplicate cu același id)
Tipuri de asociații
.JoinAlias(p => p.Genuri, () => genreAl, JoinType.LeftOuterJoin)
- LeftOuterJoin - selectează toate înregistrările din tabelul din stânga ( Carte), apoi le adaugă înregistrările de tabel potrivite ( Gen). Dacă o intrare corespunzătoare nu este găsită în tabelul din dreapta, o afișează ca Null
- RightOuterJoin este opusul LEFT JOIN - selectează toate înregistrările din tabelul din dreapta ( Gen), apoi le adaugă înregistrările din tabelul din stânga ( Carte)
- InnerJoin - selectează numai acele înregistrări din tabelele din stânga ( Carte) care are o intrare corespunzătoare din tabelul din dreapta ( Gen), apoi le unește cu înregistrările din tabelul din dreapta
Să schimbăm reprezentarea după cum urmează:
Vedere index
@modelul IEnumerable @Html.ActionLink(„Creează nou”, „Creează”)
@foreach (var articol din model) ( @Html.DisplayNameFor(model => model.Name)
@Html.DisplayNameFor(model => model.Mind)
@Html.DisplayNameFor(model => model.Series)
@Html.DisplayNameFor(model => model.Authors)
@Html.DisplayNameFor(model => model.Genuri)
Operațiuni
}
@Html.DisplayFor(modelItem => item.Name)
@Html.DisplayFor(modelItem => item.Mind.MyMind) @(string strSeries = item.Series != null ? item.Series.Name: null;) @Html.DisplayFor(modelItem => strSeries)
@foreach (var autor în item.Authors) ( șir strAuthor = autor != null ? autor.Nume: null; @Html.DisplayFor(modelItem => strAuthor)
}
@foreach (var gen în item.Genres) ( string strGenre = gen!= null ? genre.Name: null; @Html.DisplayFor(modelItem => strGenre)
}
@Html.ActionLink(„Editare”, „Editare”, nou ( id = item.Id )) | @Html.ActionLink(„Detalii”, „Detalii”, new ( id = item.Id )) | @Html.ActionLink(„Șterge”, „Șterge”, nou ( id = item.Id ))
După ce verificăm toate operațiunile una câte una, vom observa că:
- În timpul operațiunilor de creare și actualizare, toate datele asociate cu tabelul Book sunt actualizate (eliminați Cascade="save-update" sau cascade="all" și datele asociate nu vor fi salvate)
- La ștergere, datele sunt șterse din tabelele Book, Mind, Book_Author, dar datele rămase nu sunt șterse deoarece au Cascade="save-update"
Mapare pentru clasele care au moștenire.
Cum să mapați clasele care au moștenire? Să presupunem că avem acest exemplu:
//Class of Two-Dimensional Shapes public class TwoDShape ( //Width public virtual int Width ( get; set; ) // Height public virtual int Height ( get; set; ) ) // Class Triangle public class Triangle: TwoDShape ( // /Număr de identificare public virtual int Id (get; set; ) //Tipul triunghiului public virtual șir Stil (get; set; ) )
În principiu, nu este nimic complicat în această mapare; pur și simplu vom crea o mapare pentru clasa derivată, adică tabelul Triunghi.
//Cartografierea triunghiului clasă publică TriangleMap: ClassMap
După lansarea aplicației, următorul tabel (vid) va apărea în baza de date Biblioteca 
Etichete:
- asp.net mvc 4
- nhiberna
- SQL Server
Problemă
Ați descărcat un raport de contabilitate a costurilor și doriți să îl afișați conducerii. Pentru a face acest lucru, trebuie să compilați datele din elementele contabile - în funcție de elementele contabile de gestiune. Știți cum se leagă între ele articolele contabile și cele contabile, dar de fiecare dată pregătirea manuală a unui astfel de raport vă ia prea mult timp.
Soluţie
Vom considera acest caz ca o continuare a celui precedent. Să ne imaginăm că ați creat următorul director în Excel:
Fig.2.1. Director: cartografierea articolelor BU și CU
În stânga este un element de cost (AC), în dreapta este un articol contabil de gestiune (MA). Este important ca elementul de cost să apară o singură dată în prima coloană, altfel mecanismul de mapare nu va funcționa corect.
(Apropo, maparea cuvintelor în limba engleză este tradusă ca afișare sau corespondență, deci cartea de referință în în acest caz,- asta e ceva regula generala modul în care articolele BU sunt reflectate în articolele OU).
Fig.2.2. Tabel plat: raport de cost (din „Cifrarea de afaceri a contului 20”)
Vă rugăm să rețineți că în coloana a 7-a a apărut coloana „Articolul TC”. Vizavi de fiecare element de cost am plasat un articol contabil de gestiune. Acest lucru se poate face manual, dar este mult mai convenabil să utilizați acest instrument:
Fig.2.3. Tabel plat: raport de cost (din „Cifrarea de afaceri a contului 20”)
În partea de jos a formularului sunt numele paginilor: „Acasă” este un tabel plat care conține date de cost (Fig. 2.2), „spr” este o carte de referință (Fig. 2.1).
Numerele coloanelor sunt indicate în partea de sus a formularului. Deci, în acest caz, dacă datele din coloanele 1 ale directorului și 3 ale paginii principale coincid, atunci datele din coloana a 2-a a directorului sunt copiate în coloana a 7-a a paginii principale.
În această formă sunt și multe opțiuni suplimentare. De exemplu, puteți activa casetele de selectare „Atribut #2” și „Atribut #3”, iar apoi transferul datelor din coloana 2 a directorului în coloana 7 a paginii principale va fi posibil dacă directorul și pagina principală se potrivesc două sau chiar și trei detalii deodată.
Ca urmare a unei operații atât de simple folosind masă rotativă Puteți construi o serie întreagă de rapoarte analitice diferite, în care una dintre secțiuni va include analiza „Articol UU”. De exemplu, așa:
Fig.2.4. Raport de cost pentru atelierul de armare
Comparația cartografierii cu VLOOKUP()
Mulți utilizatori sunt familiarizați și folosesc funcția VLOOKUP() în aceste tipuri de situații. in orice caz Funcția VLOOKUP() funcționează bine numai pe volume mici date, în timp ce acest formular se descurcă bine cu procesarea tabelelor Excel, chiar dacă aveți, să zicem, 5.000 de rânduri în cartea de referință și 300.000 de rânduri pe pagina goav. Încercați să-l verificați și veți vedea că VLOOKUP() eșuează la astfel de volume. În plus, funcția VLOOKUP() creează o încărcare semnificativă pe Excel, forțându-l să efectueze cantități mari de calcule. Formularul de mapare evită acest dezavantaj: rulează o singură dată, durează câteva secunde (pentru volume mari de minute) și după aceea nu există încărcare suplimentară pe fisier Excel nu mai este creat.
Luarea deciziilor prompte și de înaltă calitate de către conducerea întreprinderii depinde de un sistem de contabilitate de gestiune bine construit în companie. Contabilitate de gestiune aici, în conformitate cu practica general acceptată acest termenînseamnă utilizarea principiilor contabile și de management financiar pentru a rezolva probleme în următoarele domenii ale întreprinderii:
- dezvoltarea și implementarea strategiei de afaceri;
- implementarea planificarii si controlului;
- utilizare eficientă resurse;
- creșterea eficienței operaționale;
- conservarea imobilizărilor corporale și necorporale;
- managementul proceselor de afaceri corporative și în cadrul companiei
Acces la informatii contabileîn orice caz, se realizează folosind diverse tipuri de rapoarte.
Deoarece colectarea și stocarea datelor privind activitățile economice ale unei întreprinderi este un proces destul de intensiv în muncă și costisitor, utilizarea eficientă a acestor informații devine o sarcină importantă și un avantaj competitiv. Volumul de informații colectate este determinat de conducerea companiei ca o soluție de compromis între cerințele autorităților de stat și de reglementare pentru divulgarea informațiilor și volumul maxim de informații (financiare, tehnologice, statistice) apărute în procesul activității de afaceri a întreprinderii. .
Cea mai eficientă modalitate de utilizare a informațiilor generate în procesul de activitate este crearea unui depozit de date (datewarehouse), pe baza căruia, folosind tehnologiile OLAP, orice manager de întreprindere poate genera un raport pentru analiza datelor în contextul analitic de care are nevoie. și să ofere el însuși informații pentru luarea deciziilor.
Cu toate acestea, în prezent, cea mai comună opțiune rămâne crearea unui sistem informațional în care se acumulează date și, de regulă, există un generator de rapoarte personalizate care completează rapoartele standard furnizate de dezvoltatorul sistemului.
De obicei, dezvoltatorii de software oferă utilizatorilor forme actualizate în mod regulat de raportare externă (pentru autoritățile de reglementare) (contabil și fiscal) și promovează posibilitatea de a crea orice tip de rapoarte de management cerute de întreprindere. Cu toate acestea, raportul generat nu este neapărat bine format.
Întreprinderea rămâne singură cu problema generării (completării) corecte a rapoartelor.
Necesitatea unei întreprinderi de a genera rapoarte despre Standarde internaționale nu poate decât să înrăutățească situația.
Punctul cheie în raportare în toate cazurile este necesitatea de a crea o conexiune între acreditările din sistemele informaționale și câmpurile corespunzătoare din formularele de raportare.
Sunt posibile următoarele opțiuni pentru organizarea relației:
- Sub forma unui tabel care descrie relațiile sau corespondența dintre câmpurile de raport și datele din sistem (urmat de scrierea unui algoritm pentru generarea automată a raportului).
- Prin selectarea manuală a informațiilor necesare (cu o lipsă completă a capacității de automatizare a raportului).
- O versiune mixtă, care necesită prezența tabelelor de interrelație și decodare și ajustări manuale la generarea rapoartelor.
Prima variantă de organizare a relației sistemelor de contabilitate informațională cu formularele de raportare (prin tabele care descriu relațiile) se numește „ cartografiere”.
Cartografierea (în sens larg) este transformarea datelor dintr-o formă în alta. Pentru contabilitate, maparea este compilarea unui tabel de corespondențe ale conturilor contabile din diferite planuri de conturi, de exemplu, planul de conturi rus și planul de conturi GAAP (IFRS) (sau planul de conturi al contabilității de gestiune).
Exemplul 1. Versiune mixtă a organizării comunicării.
Majoritatea companiilor pregătesc rapoarte, de exemplu conform IFRS, prin transformare. Metoda se bazează pe abordarea conform căreia informațiile generate de standardele rusești, este analizată și ajustată pentru a-l aduce în conformitate cu IFRS.
Raportarea este transformată în cel puțin patru etape folosind tabele de cartografiere și ajustări manuale.
etapa 1. Transformarea structurală a bilanțului și a contului de profit și pierdere. Rezultatul este o regrupare și o agregare a elementelor individuale din situațiile financiare pentru a pregăti o bază de date pentru înregistrările ulterioare de ajustare. În același timp, tabelul de cartografiere conține indicatorii de raportare financiară conform RAS și reflectarea acestora în raportarea intermediară conform IFRS.
a 2-a etapă. Efectuarea de intrări corective care vizează eliminarea diferențelor calitative între Reportaj rusescși raportarea conform IFRS. Realizat manual de un specialist în transformare.
a 3-a etapă. Intocmirea raportarii conform IFRS pe baza bilanturilor transformate, situatiilor de profit si pierdere si alte forme. Tabelul de cartografiere include cifre de raportare intermediară conform IFRS și o descriere a ajustărilor efectuate de specialistul în transformare.
etapa a 4-a.Întocmirea părții descriptive a raportului.
Tabelul 1. Ilustrarea interrelației dintre planul de conturi rusesc cu planul de conturi GAAP (extras)
Vânzări – activitate principală |
Vânzări/venituri – activitate principală |
||
Costul vânzărilor |
|||
Profit brut |
Vânzări nete |
||
Cheltuieli generale, de vânzare și administrative |
Vanzare cheltuieli generale si administrative |
||
Tabelele de cartografiere sunt, de asemenea, utilizate în generarea de rapoarte de management corporativ (de obicei în companiile holding și companiile cu sucursale).
Baza pentru configurarea cartografierii este într-un anumit fel(conform standardelor firmei) date contabile grupate.
Mai simplu spus, atunci când creăm o linie de raportare corporativă, indicăm exact ce cifre de afaceri (sau solduri de cont (subconturi)) și în ce ordine ar trebui utilizate sistem automat contabilitate pentru a forma această linie.
Cartografierea este regulile pe care le-ați stabilit, conform cărora vor fi generate rapoartele de care aveți nevoie. Principii tehnice Formarea liniilor de cartografiere este aceeași pentru toate formularele de raportare, singura diferență este în conținut.
În acest sens, trebuie remarcat faptul că cartografierea trebuie configurată de către specialiști calificați și, cel mai important, într-o manieră metodologică unificată. Procedura de cartografiere necesită destul de mult timp.
Baza contabilității de gestiune (precum și a contabilității) sunt: planul de conturi, articolele bugetare și diverse cărți de referință analitică.
Cu toate acestea, planul de conturi de gestiune diferă semnificativ de planul de conturi standard, care este utilizat pentru contabilitate după contabilitate, deoarece unele dintre conturile planului de conturi de gestiune (denumite în continuare MCA) pot avea analize mai detaliate și cealaltă parte poate avea analize mai cuprinzătoare (totul depinde de întreprinderile specifice). Structura cărților de referință analitică este, de asemenea, diferită, deoarece rapoartele de gestiune necesită prezentarea informațiilor contabile într-un context complet diferit de cel al rapoartelor contabile.
Desigur, în practică, legarea indicatorilor ( cartografiere) contabilitatea de gestiune, fiscală și contabilă (financiară) provoacă o mulțime de probleme.
Să ne uităm la unele dintre ele.
1. Lipsa de analiză în planul de conturi de lucru (denumit în continuare WCA) al companiei.
Acest lucru este de înțeles, deoarece întreprinderile care au fost create pentru o zi nu au avut întotdeauna o strategie pe termen lung, iar interesele acționarilor nu au fost întotdeauna respectate. Astăzi, însăși cultura de afaceri s-a schimbat. Acţionarii, inclusiv statul, manifestă un interes din ce în ce mai mare pentru modul în care managerii de la toate nivelurile gestionează întreprinderea cu competenţă şi pricepere.
Soluția la această problemă este extinderea și completarea sistemului de casă existent al companiei și acumularea treptată a informațiilor despre conturile (subconturi) nou introduse.
Înțelegerea principalelor abordări ale construirii unui Plan de conturi, precum și a celor trei componente (financiară, fiscală, de management) ale unui sistem contabil unificat într-o companie, predetermina necesitatea evidențierii a trei componente de bază într-o abordare sistematică a sistemului financiar-contabil. a unei organizații comerciale, și anume:
- contabilitate financiara);
- impozit;
- manageriale.
Mai jos sunt prezentate posibile interpretări ale componentelor financiare, fiscale și de management ale unei abordări sistematice a RPS.
Componenta financiara (contabila). Utilizarea RPS ar trebui să asigure posibilitatea generării tuturor (fără excepție) a indicatorilor contabili și analitici rezultați ai situațiilor financiare externe și a notelor explicative în contextul conturilor din Registrul general de la data raportării. Blocul conturilor contabile ale RPS implicate în formarea rapoartelor contabile externe este conturile financiare. La rândul lor, conturile financiare sunt împărțite în analitice și sintetice. Subconturi contabilitate financiara RPS sunt intermediare între analitice și sintetice. În plus, conturile financiare analitice și sintetice, precum și subconturile, pot reprezenta o parte integrantă a componentei de management a RPS. De exemplu, datele reflectate în subconturile individuale ale contului financiar 90 „Vânzări” sunt importante pentru luarea deciziilor de management.
La formarea unui grup de conturi financiare ale RPS, trebuie îndeplinite următoarele cerințe:
- între elementele de raportare contabilă externă și soldurile conturilor financiare trebuie să se stabilească o corespondență care să nu necesite operațiuni logice suplimentare pentru a determina tipul articolului de raportare;
- setul minim posibil de conturi financiare ale RPS trebuie să fie intenționat format pe baza compoziției indicatorilor de raportare financiară externă;
- fiecare indicator extern de raportare financiară trebuie să fie obținut din datele contabile financiare folosind RPS fără nicio decodare sau ajustări suplimentare.
Componenta fiscală. Utilizarea RPS în sistemul contabil oferă capacitatea de a calcula baza de impozitare și valoarea profitului în scopuri fiscale, în conformitate cu cerințele capitolului. 25 Codul Fiscal al Federației Ruse. Implementarea componentei fiscale a unei abordări sistematice a RPS implică:
- organizarea contabilității analitice financiare și fiscale a cheltuielilor și veniturilor în vederea identificării impactului acestora asupra cuantumului bazei de impozitare pentru calcularea impozitului pe profit al unei organizații comerciale prin detalierea conturilor financiare (01 - 99) RPS;
- elaborarea unei liste de conturi fiscale (de exemplu, 101–199). Implementarea acestora va face posibilă ținerea evidenței abaterilor în datele contabile ale obiectelor de contabilitate financiară și fiscală în vederea realizării contabilității fiscale și a raportării fiscale pe baza contabilității financiare și a raportării financiare;
- elaborarea unor reguli care să permită ajustarea impactului componentei fiscale asupra raportării contabile integrate unificate pentru a elimina dublarea raportării (rezultate) a indicatorilor contabili și analitici.
Componenta de management. În RPS, pentru a obține indicatorii contabili și analitici rezultați ai raportării interne de gestiune și a contabilității de gestiune, este alocat un bloc de conturi de gestiune (de exemplu, 201–299). Aceste conturi de gestiune efectuează intrare dubla ajustări ale conturilor financiare 01–99 în funcție de cerințele utilizatorilor pentru raportarea managementului intern. Pe viitor, datele privind conturile de gestiune 201–299, atunci când se folosesc anumite reguli, completează (corectează) datele privind conturile financiare 01–99. Rezultatul unor astfel de acțiuni sunt indicatori ai raportării interne a managementului.
Implementarea aspectului de management într-o abordare sistematică a formării RPS presupune dezvoltarea:
- prevederile politicii contabile (externe și interne), clarificarea criteriilor de recunoaștere a elementelor contabile, evaluarea acestora, precum și dezvăluirea conținutului elementelor de raportare de gestiune;
- subsistemul conturilor de gestiune a RPS unificat, necesar pentru înregistrarea și rezumarea abaterilor datelor contabile de gestiune de la datele contabile financiare;
- compoziția de raportare financiară alternativă a formularelor de raportare a conducerii.
În plus, atunci când se formează un bloc de conturi de gestiune pentru RPS, este necesar să se elaboreze un tabel „Relația (cartografierea) între subsistemele conturilor financiare și de gestiune cu indicatori de raportare de management alternativă”.
Tabelul 2. Harta operațiunilor contabile (financiare) contabile rusești pentru a genera linii ale formularului de raportare corporativă „Sold” (extras)
Linia de echilibru |
Cont contabil |
Selectare prin subconto 1 |
Corr. cont contabil |
Selectare prin subconto 1 |
Formula de selecție |
||
Selectare prin subconto 2 |
Selectare prin subconto 2 |
Semn invers |
|||||
Selectare prin subconto 3 |
Selectare prin subconto 3 |
Contabilitate TVA |
|||||
Selectare prin subconto 4 |
Selectare prin subconto 4 |
Extinde cu |
|||||
Selectare prin subconto 5 |
Selectare prin subconto 5 |
Participarea la un cont de grup |
|||||
BL00102 Punere în funcțiune (+) |
|||||||
Punerea in functiune (+) |
|||||||
Punerea in functiune (+) |
|||||||
Punerea in functiune (+) |
|||||||
Punerea in functiune (+) |
|||||||
Punerea in functiune (+) |
|||||||
Fără îndoială, decizia de a crea un sistem integrat de contabilitate (financiar, fiscal și de gestiune) într-o organizație comercială și de a dezvolta un plan de conturi de lucru unificat pentru un astfel de sistem bazat pe un Plan de conturi standard nu este clară. Teoretic, următoarele abordări pot fi aplicate pentru construirea unui plan de conturi de lucru pentru o organizație comercială (în cazul utilizării planurilor de conturi pentru trei tipuri de contabilitate):
- un singur plan de conturi integrat pentru contabilitatea financiară, fiscală și de gestiune;
- plan de conturi integrat pentru contabilitate financiara si fiscala, plan de conturi autonom pentru contabilitatea de gestiune;
- planul de conturi integrat pentru contabilitatea financiară și de gestiune; plan de conturi autonom pentru contabilitate fiscală;
- plan de conturi integrat pentru contabilitate fiscală și de gestiune; plan de conturi autonom pentru contabilitate financiară;
- planuri de conturi autonome pentru contabilitatea financiară, fiscală și de gestiune.
2. Probleme de construire a cărților de referință și clasificatoare, dintre care principalele sunt:
- duplicarea informațiilor în directoare;
- Codificarea incorectă a directoarelor de termeni.
Se întâmplă adesea, de exemplu, să nu existe o procedură uniformă de atribuire a codurilor și numelor; aceeași contraparte poate fi listată în director de două ori (Romashka LLC și Romashka LLC, alte opțiuni și combinații) sau sub nume diferite (de exemplu, sub complet și sub abreviat). Căutarea datelor necesare într-un sistem informațional folosind directoare nestructurate este destul de complicată și incomod. În plus, dezordinea din cărțile de referință provoacă erori în raportare.
De exemplu, fiecare întreprindere care face parte din holding, într-o anumită măsură, menține în mod independent evidențe primare, dezvoltă și actualizează propriile directoare. Această activitate în întreprinderi este de obicei efectuată diverse servicii: departamente financiare, departament de marketing, Departamentul legal etc. Toate acestea vă permit să luați decizii optime de management în cadrul unei anumite întreprinderi. Cu toate acestea, înțelegerea și capacitatea de a analiza starea actuală a exploatației în ansamblu este foarte dificilă din cauza naturii nestructurate și unificate a informațiilor.
O altă situație comună: într-una dintre companii, din cauza solicitărilor periodice din partea departamentului de marketing către departamentul de contabilitate cu privire la structura vânzărilor, contabilii au fost nevoiți să colecteze manual informații în secțiunile de informații necesare. Acest lucru s-a datorat faptului că departamentul de vânzări nu a introdus întotdeauna în director datele necesare pentru generarea automată a rapoartelor solicitate.
– Incompatibilitatea unor părți ale sistemului automatizat de contabilitate.
De exemplu, departamentul de aprovizionare menține registre și directoare ale ITC în programul Cache, iar registrele și directoarele contabile (financiare) și de gestiune sunt menținute în SAP R3, iar raportarea companiei este, de asemenea, generată acolo. Formatele de prezentare a datelor din aceste programe sunt diferite, astfel încât conversia datelor între ele este dificilă și, în unele cazuri, direct imposibilă.
La elaborarea cărților de referință, trebuie respectate următoarele principii.
– Detaliile și structura directoarelor trebuie să fie astfel încât să fie posibilă procesarea rapidă a datelor și generarea rapoartelor necesare.
Dacă cartea de referință nu este suficient de detaliată, acest lucru va îngreuna obținerea informațiilor necesare. De exemplu, dacă la jumătatea anului trebuie să aflați despre costurile producției de broșuri publicitare comandate de departamentul de marketing și înainte de aceasta toate costurile de marketing au fost luate în considerare împreună, atunci va trebui să faceți o selecție suplimentară de informații bazate pe dovezi indirecte (de exemplu, de către tipografii). (Pentru holdinguri sau grupuri de companii, detaliile directoarelor vor depinde de cerințele de structurare a informațiilor nu numai ale unei întreprinderi individuale, ci și ale întregului holding.)
Dacă cartea de referință este foarte detaliată, atunci este dificil să o completezi cu informații și să o folosești în munca ta. De exemplu, directorul „Flux de numerar” poate conține mai mult de o mie diverse scopuri plată. Pregătirea unui raport de flux de numerar pentru plățile de bază pentru directorul general va dura mult timp, deoarece va trebui să efectuați gruparea necesară (agregarea indicatorilor sau selectarea informațiilor necesare dintr-o serie de informații redundante). În plus, atunci când introduce informații, este posibil ca utilizatorul să nu știe unde să includă o anumită plată. Acest lucru va duce inevitabil la o selecție incorectă a articolelor din director sau la clasificarea plății ca „altele”. Se poate recomanda să se descrie în detaliu ce obiecte contabile pot fi reflectate pentru fiecare linie a directorului.
– Codarea elementelor directorului ar trebui să elimine duplicarea informațiilor și să ajute la accelerarea lucrului cu directorul. Înainte de codificarea datelor, este necesar să se determine în care dintre sistemele de informații ale întreprinderii vor fi stocate directoarele de referință. Posibilitatea de a utiliza anumite coduri va depinde în mare măsură de capacitățile sistemului. Un astfel de sistem poate fi un program de contabilitate, informații din care sunt transferate automat către alte sisteme care folosesc aceleași directoare.
– Ar trebui să evitați utilizarea unor codificări similare în directoare diferite.
De exemplu, dacă, la analiza vânzărilor, departamentul de marketing identifică grupuri de cumpărători nu după regiune, ci după oraș și regiune, atunci grupurile pentru analiză nu ar trebui să coincidă cu codurile regiunilor federale. În caz contrar, acest lucru va duce la erori la introducerea informațiilor. Astfel, codul „77” este setat pentru Moscova, iar regiunea Belgorod este listată sub acest cod la întreprindere. Drept urmare, un angajat poate atribui un anumit tip de vânzări nu regiunii, ci Moscovei, iar informațiile vor fi distorsionate. În acest caz, se recomandă să creați coduri de lungimi diferite, de exemplu, pentru a codifica grupuri de marketing, utilizați trei cifre (cod „770” pentru clienții din regiunea Belgorod);
– Ideal Codul directorului nu trebuie să depășească 8 caractere. În caz contrar, datele sunt dificil de introdus, deoarece codurile nu se disting cu ușurință unele de altele.
– la crearea directoarelor interconectate, duplicarea ar trebui eliminată. Pentru a evita erorile în directoare (datorită naturii nesistematice și haotice a completării acestora), este necesar să se analizeze informațiile conținute în acestea pentru a identifica datele care pot fi generate de directoarele individuale.
– Fiind dezvoltat sistem unificat directoare, este necesar să se asigure protecția acestuia împotriva modificărilor neautorizate. Securitatea suficient de ridicată poate fi obținută de obicei atât prin utilizarea metodelor de identificare a utilizatorilor, cât și prin delimitarea drepturilor de acces ale utilizatorilor la informații. Cel mai adesea, pentru a crea și menține directoare, companiile dezvoltă reglementări care îi determină pe cei responsabili cu introducerea informațiilor în directoare și modificarea acestora.
În concluzie, trebuie spus că este necesar să se rezolve problemele de mai sus înainte de a configura maparea. În caz contrar, este puțin probabil să se poată genera rapoarte de management. Chiar dacă se generează raportări, probabilitatea ca aceasta să fie corectă este practic zero. Motivele sunt evidente:
- Erori care vor apărea din cauza problemelor descrise anterior.
- Erori contabile (atât metodologice, cât și contabile). Oamenii țin evidențe, nu uitați asta.
- În continuare, ar trebui să oferim o listă lungă de diferite tipuri de erori, a căror sursă va fi rezultatele suprapunerii paragrafelor 1 și 2. Cu toate acestea, în opinia noastră, acest lucru este inutil.
