1s преизчисляване. Корекции и преизчислявания на заплати. Предимство по срок на валидност

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

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

Като цяло записите в таблицата за преизчисляване съдържат следните полета:

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

Записите могат да се съхраняват по-подробно, в контекста на едно или няколко измерения на даден изчислителен регистър. Например регистраторът на заплатите за целия отдел беше със задна дата; Освен това промените бяха само за служителя Иванов. Добавянето на измерението Служител към Преизчисляване ще ви позволи да проследите това. В този случай измерението за преизчисляване трябва да бъде свързано с измерението на регистъра за изчисление:

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

Въпрос 14.41 от изпита 1C: Platform Professional. Данни за преизчисление...

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

Верният отговор е първият, те обикновено се съхраняват в отделни таблици.

Въпрос 14.42 от изпита 1C: Platform Professional. В прозореца със свойства на измерението "Преизчисляване", в раздела "Комуникация", в свойството "Регистриране на измерение", посочете...

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

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

Въпрос 14.43 от изпита 1C: Platform Professional. Таблицата "Преизчисляване" е попълнена с редове, всеки от които представлява...

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

Първият отговор е правилен, анализ по-горе.

Въпрос 14.45 от изпита 1C: Platform Professional. Изберете верният отговор:

В процеса на работа с преизчисления, разработчикът може да „игнорира“ информацията, която системата предоставя в таблицата за преизчисление, тоест да откаже да преразгледа резултатите от изчислението
Принципът на действие на преизчисленията в системата 1C:Enterprise 8 е „уведомяване“
Разработчикът на конфигурацията не може да контролира процеса на преизчисляване на записи в регистъра за сетълмент; системата прави всичко автоматично
Твърдение 1 и 2 са верни

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

Въпрос 14.46 от изпита 1C: Platform Professional. За един изчислителен регистър...

Може да се поддържа само едно преизчисляване
Могат да се поддържат само три разпределения на различни структури
Поддържат се произволен брой преизчисления на различни структури

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

Въпрос 14.57 от изпита 1C: Platform Professional. Честотата на сетълментите е месечна. В регистъра на изчисленията са направени съответните настройки. За типа изчисление на заплатата типът изчисление на пътуването е посочен като изместващ тип изчисление. На 01.03.14 г. информацията за заплатите е въведена в информационната база, но не е направено изчисление. На 20.03.14 г. командировката е въведена в информационната база и изчислена. На 30.03.14 г. стартира изчисляването на заплатите. Ще се вземат ли предвид данните за командировката при изчисляване на заплатата? Трябва ли да преизчисля командировката си?

Ще се вземе предвид, но командировката ще трябва да се преизчисли
Ще бъдат взети предвид, не е необходимо преизчисляване на пътуването
Няма да се вземат предвид. Необходимо е да отмените изчислението на пътуването и да преизчислите двата вида изчисление
Няма да се вземат предвид. За да направите изчислението правилно, заплатата и командировката трябва да са в един документ

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

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

Теория

Изчислителен регистър (RR)- обект на метаданни за конфигурация, използван за изпълнение на периодични изчисления в системата 1C. Очевидните области на приложение на изчислителните регистри включват следното: изчисляване на заплати, изчисляване на наем, изчисляване на наем.

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

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

механизъм на потискане по период на действие«:

Тук виждаме, че тип калкулация „Командировка” е с продължителност във времето и е валидна от 10 април до 20 април, като изместващ тип калкулация за вид калкулация „Заплата” е посочена „Командировка”. „Заплатата“ също се простира във времето и е валидна от 1 април до 30 април. Тъй като „Командировка” е посочена като изместващ вид изчисление за вид изчисление „Заплата” (с по-висок приоритет от заплата) и важи за периода на валидност на заплатата, то заплатата се измества от командировка и се формира „Действителен период на валидност на заплатата.” Действителен период на валидност на заплатата „Това е периодът на валидност на заплатата след командировка, в нашия случай той се състои от 2 периода - от 1 април. до 9 и от 21 до 30 април и общо е 19 дни. Базираният на периода механизъм за изместване работи само за дългосрочни изчисления.

Фигурата по-горе показва графично принципа на " механизъм на зависимост по базов период«:

Да приемем, че в края на април 2017 г. искаме да дадем на служител бонус в размер на 10% от заплатата. Заплатата е посочена като основен вид изчисляване на бонусите.

Но като „база“ за изчисляване на премията няма да вземем целия месец април, а само интервала от 10 април до 20 април (11 дни). Нека изчислим базата за бонуса, заплатата на служителя е 60 000 рубли, има 30 дни в месеца, дневна заплата = 60 000/30 = 2000 рубли. Следващи 2000*11 = 22000 рубли. Основата за изчисляване на премията е 22 000 рубли.

Нека изчислим премията: (22000/100)*10 = 2200 рубли. Бонус от 10% от заплатата е 2200 рубли.

Обектът на метаданни на приложението „План на видове изчисления“ е тясно свързан с регистъра на изчисленията.

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

Един изчислителен тип план може да се използва в няколко изчислителни регистъра, но един изчислителен регистър не може да използва няколко изчислителни типа планове едновременно.

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

Механизмите за изчисление в системата 1C Enterprise са проектирани по такъв начин, че първо трябва да направите записи в регистъра за изчисления и едва след това да извършите изчислението въз основа на тези данни. Например, невъзможно е да се изчисли бонус въз основа на заплата, докато същата тази заплата не бъде записана в регистъра за изчисления.

Практикувайте

Нека разгледаме по-отблизо изчислителните регистри на практика:

Етап 1Да започнем с план за видовете изчисления. Трябва да създадете план за тип изчисление, преди да създадете регистър за изчисления. Създаваме план за типовете изчисления преди регистъра на изчисленията, тъй като преди да създадем таблица за съхраняване на изчислените данни (т.е. регистър на изчисленията), е необходимо да посочим алгоритмите за изчисляване на тези данни (т.е. план за видовете изчисления).

Нека създадем план за видовете изчисления „Основни такси“. Нека веднага отидем в раздела „Изчисление“. Тук веднага виждаме знамето " Използва период на валидност", когато този флаг е зададен, всички видове изчисления, включени в този план, ще имат дължина във времето(например Заплата, Командировка), а също и за този план от видове изчисления, “ механизъм на потискане по период на действие". Ако флагът „Използва периода на валидност“ не е зададен, тогава видовете изчисления няма да имат удължаване във времето (например Бонус, Глоба) и „механизмът за изместване по период на валидност“ няма да работи. Също така в този раздел има раздели „Зависимост от основата“ и „Основни планове за видове изчисления“ - те служат за изпълнение на „ механизъм на зависимост по базов период“, но ще говорим за това по-късно. Засега нека оставим „Зависимост от базата“ в режим „Независим“.

Нека създадем предварително дефиниран тип изчисление „Заплата“. В раздела „Основни“ всичко е просто. Задайте името и кода на типа изчисление.

Благодарение на факта, че поставихме знамето " Използва период на валидност„Вече имаме раздел“ Изместване" и се включи " основан на периода репресивен механизъм«.

В този раздел посочваме видовете изчисления, които ще изместят заплатата по период на валидност (например Командировка).

Забележка: в „Преместване“ можете да добавите типове изчисления, които принадлежат само към този план от типове изчисления.

Има и раздел " Водещи»—показва типовете изчисления, които при промяна трябва да преизчислят текущия тип изчисление. Тук можете също да посочите видове изчисления от други планове за изчисления. Например типът изчисление „Заплата” е водещият за типа изчисление „Бонус”, т.е. Когато се промени заплатата, трябва да преизчислим и бонуса, защото Бонусът се изчислява в зависимост от заплатата. В този случай типът изчисление „Заплата“ принадлежи към PRP „Основни начисления“, който използва период на валидност, а типът изчисление „Бонус“ принадлежи към PRP „Допълнителни начисления“, който не използва период на валидност.

Стъпка 2.Нека създадем директория “Charts” със структурата по подразбиране. В директорията “Графици” ще съхраняваме работното време на служителите (петдневно, шестдневно и др.).

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

Нека създадем непериодичен независим информационен регистър „Работни графици“ с 2 измерения „Дата“ и „График“ и ресурс „Брой часове“.

Благодарение на информационния регистър „Работни графици“ ще можем да изчисляваме заплатите от заплатата пропорционално на броя на отработените дни.

Стъпка 4.Създайте документ „Заплати“ със структурата на детайлите, показана по-долу:

Реквизити:

Оперативното изпълнение е настроено на „Забрана“защото няма смисъл за механизма на периодични сетълменти в 1C - ние никога не изчисляваме бонуси, заплати или глоби в реално време.

Нека създадем формуляр на документ с настройки по подразбиране.

Стъпка 5. Най-накрая стигнахме до момента на създаване на изчислителни регистри.

Обектът с метаданни на регистъра за изчисление се намира в клона „Регистри за изчисление“ на конфигуратора.

Нека създадем регистър за изчисления „Основни такси“. Нека да разгледаме настройките на регистъра за изчисления по-долу:

1. В полето „План за типове изчисления“ посочете PVR „Основни такси“, създадени в стъпка 1.

2. Задайте флага „Срок на валидност“ на „Вярно“, защото PVR, посочен в стъпка 1, има удължаване във времето.

След задаване на този флаг стандартните детайли „Период на действие“, „Начало на период на действие“, „Край на действие“ незабавно стават достъпни за нас, което означава, че типовете изчисления, регистрирани в този регистър на изчисленията, също имат дължина във времетои имаме достъп до " механизъм на потискане по период на действие«.

P.S. Ако посочите PVR, който има дължина във времетоза RR с флаг „Период на валидност“, зададен на „False“, тогава този PVR ще работи като PVR, който няма удължаване във времето.

3. След задаване на флага „Валиден период“ на „Вярно“, полетата „Графика“, „Стойност на графиката“, „Дата на графика“ стават достъпни за нас.

В полето „График“ посочваме информационния регистър „Работни графици“, създаден в стъпка 3.

В полето „Стойност на графика“ посочваме ресурса „Брой часове“ в информационния регистър „Работни графици“.

В полето „Дата на графика“ посочваме измерението „Дата“ на информационния регистър „Работни графици“.

4. В полето „Честота” посочваме стойността „Месец”, това означава, че данните ще се въвеждат в регистъра ежемесечно.

По-долу е структурата на метаданните на регистъра:

Флагът „Основно“ за измерение засяга само производителността; не е необходимо да го задавате, но ако го направите, полето „Служител“ ще бъде индексирано.

Измерението "Служител" - използва се в " механизъм на потискане, базиран на периода на действие" И " механизъм на зависимост от базисния период«.

Ресурс „Сума“ - там ще бъде записана изчислената заплата.

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

Атрибутът „Параметър“ ще съхранява стойността на заплатата.

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

Посочваме документа като регистратор " ТРЗ“ създаден в стъпка 4.

Стъпка 6. Извършваме движения според калкулационния регистър „Основни такси“.

Нека се върнем към документа „Заплати“, създаден в стъпка 4.

Нека опишем обработката на осчетоводяването в обектния модул на документа:

Фрагмент от код за обработка на документи

1C (Код)

Процедура ProcessingProcessing(Failure, Processing Mode) // регистрирайте BasicAccruals на Movement.MainAccruals.Write = True; Movements.MainAccruals.Clear(); Регистрационен период = Начало на месеца (дата); За всяко движение на TechLineMainAccruals от цикъла MainAccruals = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Период на регистрация; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Край на процедурата

ProcessingProcedure(неуспех, режим)

// Основен регистър на начисленията

Движения. Основни начисления. напиши = вярно;

Движения. Основни начисления. Clear() ;

Регистрационен период = Начало на месеца (дата) ;

За всеки TechLine BasicAccrualsFrom BasicAccrualsCycle

Движение = Движения. Основни начисления. Добавяне();

Движение. Storno= Невярно;

Движение. Тип изчисление=TexLineMainAccruals. Тип изчисление;

Движение. PeriodActionStart = TechLineMainAccruals. Начална дата;

Движение. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ;

Движение. Регистрационен период = Регистрационен период;

Движение. Служител = TechLineMainAccruals. служител;

Движение. Диаграма = TechLineMainAccruals. График;

Движение. Параметър = TechStringMainAccruals. размер;

EndCycle;

Край на процедурата

Нека създадем тестов документ и да го стартираме:

Да отидем на „Движения на документи“:

Виждаме, че периодът на регистрация е зададен в началото на месеца, защото Честотата на RR е посочена като „Месец“. Виждаме също, че всички полета с изключение на сумата са попълнени (заплатата все още не е изчислена).

Стъпка 7.Да напишем кода за изчисляване на заплатите.

Нека създадем общ модул "Изчисление" със следните флагове:

Самото изчисление ще се извърши в този общ модул.

Нека напишем функцията за експортиране „Изчисляване на таксите“ в модула „Изчисляване“:

Тъй като попълнихме полетата „График“, „Стойност на график“, „Дата на график“ в настройките на RR „Основни такси“, виртуална таблица на регистъра на изчисленията стана достъпна за нас DataGraphics,в заявка към виртуална таблица се интересуваме от следните полета:

„Брой часове действителен период на действие“ —съдържа броя на действително отработените часове, изчислен въз основа на данните от графика

„Брой часове Период на действие“ -съдържа броя на работните часове, изчислен въз основа на данните от графика в изчислителния период

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

1C (Код)

Процедура CalculateAccruals(Регистратор, набор от записи) Експорт //Заявка за заплата=Нова заявка; Query.Text="SELECT | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData.NumberofHoursActionPeriod, 0) AS HoursPlan, |BasicAccrualsG raphicsData ica.Номер на ред |ОТ |Регистър на изчисленията.Основни начисления. Графични данни (| Регистратор = & Регистратор | И Тип на изчислението = & Тип на изчислението Заплата) AS Basic AccrualsDataGraphics"; Request.SetParameter("Регистратор", Рекордер); // предаване на документа на регистратора, така че търсенето да се извършва само на текущия документ Request.SetParameter("Calculation TypeSalary", Планове на видовете изчисления. Основни начисления. Заплата); //задайте вида на изчислението заплата, защото изчисляване на заплатата Selection=Request.Run().Select(); SearchStructure=Нова структура; SearchStructure.Insert("Номер на ред",0); //създаване на структура за търсене на данни за изчисление по номер на ред за всеки запис от RecordSet цикъл //цикличен набор от записи на текущия документSearch Structure.LineNumber=Record.LineNumber; //попълнете номера на реда за търсене If Selection.FindNext(Search Structure) Тогава //ние търсим в извадката данни за изчисление въз основа на текущия номер на ред Record.Sum =?(Selection.HoursPlan=0.0, Selection.HoursFact /Sample.HoursPlan * Sampling .Parameter); //изчисляване на заплатата пропорционално на отработените дни, в Параметър - текуща заплата EndIf; Избор.Нулиране(); //нулиране на селекцията, имаме нужда от следващия запис от набора записи, за да търсим през селекцията първо EndCycle; Recordset.Write(, True); //запишете изчислените записи в базата данни, подайте параметъра Replace = True EndProcedure

//Заплата

Заявка=Нова заявка;

Заявка. Текст = "ИЗБЕРЕТЕ

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActualActionPeriod, 0) AS HoursFact,

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS HoursPlan,

| BasicAccrualsDataGraphics.NumberLines

| ОТ

| Регистър на изчисленията. Основни начисления. Графични данни (

| Записващо устройство = &Записващо устройство

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

Нека да започнем. Първо, преизчисленията се извършват в момента, в който разглеждате заплатата като документ „Заплата“. За целта предоставя раздел „Допълнителни начисления, преизчисления”. Първото нещо, което искам да ви посъветвам: винаги проверявайте данните на етикета „Допълнителни начисления, преизчисления“ . Те могат да се появят там без ваше знание и няма да разберете защо сумата в изчислението не е същата.

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

Как програмата знае кого трябва да преброя и за кой месец?

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

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

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

Много счетоводители възприемат този съвет като означаващ, че имат нова работа, която вече им е достатъчна. Но ако не се изкачите там, няма да разберете логиката на работата и ако програмата е като черна кутия за вас, тогава няма да се сприятелите с нея. Приятелството започва с разбирането на вътрешния свят на приятел! Ако не ви е грижа за вътрешния свят на опонента ви, той не ви е приятел.

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

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

1. Разбирате ли вече как се появяват линиите? Страхотен.

2. При попълване на документа „Заплати“ и осчетоводяването му въз основа на редовете в регистъра се извършва преизчисляване и попълване на таблицата "Допълнителни начисления, преизчисления."

3. Преизчислените служители се премахват от регистъра и той става празен.

4. При анулиране на документ “Работна ведомост” редовете се връщат на мястото си, така че при повторното им попълване всичко ще си дойде на мястото.

Четвърти съвет (може би това ще бъде поправено): Преди да попълните отново документа „Работна ведомост“, разгънете го!

Въз основа на алгоритъма, след осчетоводяване на документа, регистърът се изчиства. Ако го попълните отново, без да го изчистите, програмата няма да знае кой трябва да бъде преброен и табличната част с преизчисления ще бъде празна. Това беше вярно за издание 21. Все още нямах време да го проверя в 22-ро.

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

P.S. (важно)

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

Това се случи в демонстрационната база данни, когато едно задание беше изпълнено повторно. И когато прехвърлите 1C Accounting 3.0 в 1C ZUP 3.0, ще повторите всичко, което е възможно:

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

Много 1C програмисти никога не са се сблъсквали с компонента „Изчисление“ в практиката си, следователно, когато трябва да се явят на изпити за специалист по платформа 8.0, където всяка задача съдържа задача за сложни периодични изчисления, възникват трудности, предимно трудности с разбирането.

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

Например ще използваме конфигурацията на рамката, инсталирана по време на изпити.

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

Какво представляват изчисленията

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

служител	Период	Вид изчисление	Резултат	Данни	Коментар
Измерване	Официален	Официален			Реквизит

Стойността в колона „Данни“ отразява основната заплата на служителя (според трудовия договор), но тази сума може да бъде увеличена с бонуси, намалена с глоби и отсъствия и т.н., следователно след това се въвежда действителната сума за плащане изчислението в колона „Резултат“. Това е изчислението. Сумата в графа „Ресурс” за даден служител е дължимата му заплата.

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

Всеки запис в регистъра за сетълмент се отнася за определен тип сетълмент и период от време.

Видове изчисления

Всеки запис от типове изчисления има сервизен атрибут - тип изчисление.

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

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

Типовете изчисления се използват функционално за отразяване на влиянието на записите в регистъра на изчисленията един върху друг. Но накратко те говорят за влиянието на типовете изчисления един върху друг:

Вид изчисление	Описание	Пример
По базисен период	Резултатът от изчисляването на зависимия период зависи от резултата от базовия период. Ако резултатът от базовия период се промени, резултатът от зависимия период трябва да се преизчисли.	Бонусът зависи от заплатата за базовия период.
Избърсване по период	Периодът на валидност на зависимия период замества периода на валидност на базовия период, така че базовият период има действително	Отсъствието се отразява на действителния период на заплатата.
Водещи изчисления	Изчислението зависи от водещото изчисление, но не пряко, а косвено, т.е. изчисление A зависи от основното изчисление B, а изчисление B зависи от основното изчисление B, следователно A косвено зависи от B, т.е. A зависи от водещото изчисление B. Всъщност, когато изчислението C се промени, B може да се промени и следователно може да се промени A. Системата не проследява автоматично такива сложни зависимости, така че трябва да посочите кои изчисления са водещи.	Бонусът зависи от основата на заплатата, но косвено зависи и от отсъствията.

Поради това влияние периодът на валидност на записа в регистъра за сетълмент е разделен на четири периода:

Период	Описание
Регистрационен период	В какъв период е записано събитието, т.е. обикновено при въвеждане на документ.
Валидност	В какъв период действа събитието, т.е. към кой период принадлежи събитието.
Базов период	Има значение само за периоди, които имат базов период - описва интервала на базовия период.
Действителен срок на валидност	Ако периодът на валидност е заменен от други видове изчисления, тогава действителният период на валидност се състои от няколко периода, когато този тип изчисление действително е в сила.

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

Времеви графики

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

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

Измерение, което свързани с изчислителния регистър обикновено носикоето означава "тип графика".

дата	Тип диаграма	Значение
11.01.05 пт	Пет дни
11.01.05 пт	Шест дни
12.01.05 сб	Пет дни
12.01.05 сб	Шест дни

Защо да използвате измерението на датата, а не регистъра на периодичните детайли? Всичко е много просто - ако в петък, 11 януари, имаме 8 работни часа в петдневен период, това не означава, че на следващия ден отново ще имаме 8 работни часа. Но ако използвахме периодичен регистър, стойността за следващия ден ще бъде взета от предишния ден при липса на записи.

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

Преизчисляване

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

За това са преизчисленията.

Ако изчислим основните записи, системата ще отбележи в разпределенията, че трябва да изчислим зависимите записи. След като изчислим зависимите записи, разпределенията ще бъдат изчистени.

По същество преизчисленията са списък от записи в регистъра на изчисленията, които трябва да бъдат преизчислени.

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

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

Практическа задача

Стига теория. Нека се опитаме да проучим подробностите на практика. Нека вземем за основа конфигурацията на рамката.

Формулиране на проблема:

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

Нека командировъчните се изплащат в двойна заплата + фиксирана сума на плащанията за всеки ден от пътуването.

Нека на служителя бъде наложена глоба в размер на половината от заплатата за периода на отсъствие за отсъствие.

Напредък:

Първоначално обучение

Нека създадем нов план за типове изчисления „Основни“.

Да дефинираме видовете изчисления и зависимостите между тях:

	Основен	Изместване	Водещи
Заплата		Отсъствие от работа, командировка
награда		Отсъствие от работа, командировка	Заплата, Отсъствия, Командировка
Командировка
Отсъствие от работа

Нека добавим тези типове изчисления към плана за типове изчисления „Основни“ и задайте зависимостите в свойствата на типовете изчисления според таблицата.

В регистъра за изчисляване на заплатите ще създадем измерението „Служител“ от тип „Лични лица“ - така че регистърът да има раздел за анализ на служителите.

Конфигурацията вече съдържа документ „Заплати“.

Той има две дати в заглавката - “дата” и “период на регистрация”, както и две дати “начална дата” и “крайна дата” на всеки ред.

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

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

Модулът за документи ще изглежда по следния начин:

За За всеки TechStringListОт списък цикъл

// регистър на изчисленията

Движение = Движения .Изчисления.Доп();

Движение .С торно= невярно;

Движение .В idCalculation = TechStringList.CalculationType;

Движение .PeriodActionsStart= Начало на деня ( TechStringList.StartDate);

Движение .PeriodActionEnd= EndDay();

Движение .Регистрационен период = Регистрационен период;

Движение .BasicPeriodStart= Начало на деня ( TechStringList.StartDate);

Движение .BasePeriodEnd= Краен ден ( TechStringList.Крайна дата);

Движение .Служител = TechStringList.Employee;

Движение .График = TechStringList.Graph;

Движение .Резултат = 0;

Движение .Данни = TechStringList.Size;

Краен цикъл;

Атрибутът Reversal е необходим за обръщане на записи (аналогично на знак минус).

Посочваме вида на изчислението и задаваме датите за начало и край на деня. Разбира се, базисният период може да се въвежда само за типове изчисления, зависещи от базата, а Данните могат да се въвеждат само за заплатата, но всичко работи по този начин.

Ние ще датираме всички документи 20.01.2003 г., периодът на регистрация ще бъде зададен на 02.01.2003 г. (изрично не посочвам началните и крайните данни, това тук няма значение, така или иначе, когато записвате в Регистрационен периодпреобразувани към началото на периода 01.01.2003 г.). Използваме януари 2003 г., тъй като работните графици са изпълнени за този период.

Нека създадем преизчисление „Преизчисляване“ и да добавим към него измерението „Служител“, свързано с измерението „Служител“.

Игра с преизчисления.

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

ИЗБИРАМ

Изчисления Преизчисляване. Относно обекта Преизчисляване,

CalculationsRecalculation.In ИД на изчисление,

Изчисления Преизчисляване.От служител

ОТ

Регистър за изчисления. Изчисления. ПреизчисляванеКАК ИзчисленияПреизчисляване

Ще генерираме три документа - първо ще начислим заплати на служители А и Б. Служител А работи от 1 до 31 януари, Б работи от 1 до 20 януари. Вторият ще назначи бонус на служител Б за периода от 1 до 31 януари, третият ще назначи отсъствие на служител А от 20 до 25 януари.

Играем с действителния период на валидност.

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

Нека създадем заявка и видим, че периодът на заплатата на служител А е разделен на два периода - от 1 до 19 януари и от 26 до 31 януари. Надявам се разбирате, че периодът беше разделен на две, защото... отсъствието замества заплата.

Мисля, че механизмите на действие на изчислителния регистър се изясняват пред очите ни.

Да изучаваме графики.

Сега нека се опитаме да изчислим заплатата въз основа на заплатата на служителя.

Нека създадем нова заявка за регистъра за изчисление, използвайки виртуална таблица Изчислителни регистри. Изчисления. DataGraphics. Можете да зададете параметър за тази виртуална таблица - условие за избор на записи, например Employee=&Изберете EmployeeИ Calculation Type=&Тип на изчислениеИ Graph=&ViewGraphic.

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

Колона с резултати	Значение
ValuePeriodAction	За какъв срок на валидност в часове е вписването в регистъра.
ValueActualPeriodAction	Колко часа всъщност е работил служителят?
ValueBasePeriod	За заплата няма смисъл, за бонуси - броя на работните часове в базисния период.
ValueRegistration Period	Колко работни часа има в регистрационния период (месец януари)

Преизчисленията са неразделна част от изчисляването на заплатите. Информацията за отпуск по болест, отпуск или отсъствие на служители, получена от счетоводния отдел с известно закъснение, води до преизчисляване на заплатите и съответно застрахователните премии. Експертите на 1C говорят за това как изчисленията и преизчисленията на застрахователните премии се отразяват в счетоводството и регулираното отчитане в програмата 1C: Заплати и управление на персонала 8, издание 3.

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

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

Съгласно клауза 1.2 от Процедурата за попълване на изчислението на застрахователните премии, дадена в Приложение № 2 към заповедта на Федералната данъчна служба на Русия от 10.10.2016 г. № ММВ-7-11/551@, платецът е длъжен да направи необходимите промени в изчислението и да представи актуализиран отчет на данъчния орган, ако има неотразена или непълна информация, както и грешки, водещи до подценяване на размера на дължимите застрахователни премии.

Когато решава дали да представи актуализирана калкулация, счетоводителят трябва да отговори на следните въпроси:

дали цялата информация е отразена;
дали са допуснати грешки и дали те са довели до подценяване на размера на дължимите застрахователни премии.

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

Актуализирано изчисляване на застрахователните премии

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

Типове често срещани грешки, които изискват задължително представяне на актуализирано изчисление:

1. Служителят не съобщи своевременно за промени в личните си данни и Федералната данъчна служба предостави невярна информация за него в раздел 3 от изчислението.

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

3. В началния етап на настройка на програмата 1C: Заплати и управление на персонала 8 беше направена грешка чрез изключване на премията от базата за изчисление на застрахователните премии. Коригирането на грешката ще доведе до начисляване на допълнителни такси.

4. Отдел с преференциална тарифа губи правото да я ползва, но информацията достига до ТРЗ със закъснение. Преизчисляването по основната тарифа води до увеличение на размера на дължимите застрахователни премии.

5. При изчисляване на застрахователните премии програмата не посочи, че длъжността е включена в списъка на опасните професии, които подлежат на допълнителни тарифи. След като грешката беше открита и коригирана, преизчисляването доведе до недоплащане на застрахователни премии по допълнителни ставки.

Нека да разгледаме характеристиките на преизчисляването на застрахователните премии в „1C: Заплати и управление на персонала 8“ издание 3, използвайки примери.

Пример 1

При изчисляване на застрахователните премии за единица Наличностбеше приложен преференциален размер на застрахователните премии Жители на технологично-иновационната специална икономическа зона(тарифен код “05”). Тази тарифа предвижда вноски за пенсионния фонд в размер на 13% през 2018 г.; във Фонда за обществено осигуряване 2,9%; във Федералния фонд за задължително медицинско осигуряване 5,1%. Точно така са изчислени вноските за служителя В.С. Айви. С месечна печалба от 10 000 рубли. Размерът на осигурителните удръжки за месеца беше:

в пенсионния фонд - 1300 рубли;
в FFOMS - 510 рубли;
във Фонда за социално осигуряване - 290 рубли.

Посочените суми са отразени в калкулацията на застрахователните премии за първо тримесечие на 2018 г.

Когато се оказа, че поделението е загубило правото да прилага преференциален размер на застрахователните премии, тогава в съответствие с писма на Федералната данъчна служба на Русия от 25 октомври 2017 г. № GD-4-11/21611@ и Министерството на финансите на Русия от 18 декември 2017 г. №? 03-15-06/ 84443 имаше нужда от представяне на изясняващо изчисление. За формирането му е необходимо да се преизчислят застрахователните премии с нови ставки.

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

В пример 1 организацията е настроена на Основен размер на застрахователната премия(тарифен код „01“), предвиждащ ставки за вноски през 2018 г.: в Пенсионния фонд на Руската федерация в размер на 22%; Фонд Социално осигуряване 2,9%; FFOMS 5,1%. Очевидно е, че Пенсионният фонд е „недоплатил” 9% от вноските (22% - 13%), а тарифният код е сменен.

В разглеждания пример 1, за да се преизчислят вноските, трябва да се преразгледа процедурата за отчитане на приходите. Документът е предназначен да регистрира процедурата за записване на доходи и преизчисляване на застрахователни премии от предходния период. (меню Данъци и такси). На отметката Информация за доходитенеобходимо е ръчно да се изяснят всички доходи на служителите. В същото време, на отметката Очаквани вноскиЗастрахователните премии ще бъдат преизчислени автоматично.

В резултат на преизчисляване на застрахователни премии на служителя В.С. Айви с месечна печалба от 10 000 рубли. Размерът на осигурителните удръжки за месеца беше:

в Пенсионния фонд на Русия - 2200 рубли;
във Федералния фонд за задължително медицинско осигуряване и Фонда за социално осигуряване - сумата не се е променила и възлиза съответно на 510 рубли. и 290 rub.

След преизчисляване на застрахователните премии за първото тримесечие трябва да се изготвят уточняващи изчисления. Използване на услугата 1C-отчитане,необходимо е да се създадат нови справки за коригираните периоди и за Заглавна страницапосочвам Номер на корекция(фиг. 2). Разясненията засегнаха всички служители на отдела, тъй като тарифният код на всички беше сменен. Поради това Раздел 3 в актуализираната Калкулация се формира за всички служители на отдела. В други случаи, когато формирането на актуализирано изчисление е причинено от промени в данните или начисления на отделни служители, Раздел 3 показва данни само за тези служители. Във всеки случай останалите раздели на уточняващото изчисление се попълват с напълно нови данни.

Ориз. 2. Заглавна страница на уточняващия разчет на застрахователните премии за първо тримесечие на 2018 г

Право на подаване на актуализиран Разчет на застрахователните премии

Застрахованите лица могат да представят в инспекцията актуализирано Изчисление, ако установят грешки, които водят до надценяване на размера на застрахователните премии. Всъщност при следващото изчисляване на вноските в текущия период се прави преизчисляване и резултатът се отразява в отчета за следващия период. Опции за ситуация, които ви позволяват да представите актуализирано изчисление:

1. На служителя е изплатена заплата за целия отработен месец. Изчисляването на застрахователните премии беше представено на Федералната данъчна служба, но по-късно се оказа, че служителят е в отпуск по болест или на почивка за своя сметка. Начисление, което не е включено в базата за изчисляване на премиите, замени начисляване, предмет на застрахователни премии, което доведе до надплащане на премии.

2. Всяко преизчисляване на начисленията на служителите, което води до преизчисляване на застрахователните премии в посока тяхното намаляване.

Пример 2

При изчисляване на заплатите за юни на служителя С.С. Горбунков беше награден:

изплащане на заплата - 7500 рубли;
плащане за командировка (въз основа на средната печалба) за юни - 2500 рубли.

Застрахователните премии са изчислени по основния курс. През юни вноските от заплатата на S.S. Горбунков бяха:

в Пенсионния фонд на Русия - 2200 рубли;
в FFOMS - 510 рубли;
във Фонда за социално осигуряване - 290 рубли.

Тези вноски са платени и включени в сметката за полугодието на 2018 г. Представеният в счетоводството болничен лист за периода 25.06.2018 г.-30.06.2018 г. не създава основание за формиране на актуализирано Разчет. Документ, регистриран в програмата Отпуск по болестсторнира предварително начислената сума на командировъчните (фиг. 3).

Ориз. 3. Преизчисляване на командировъчните в документ „Отпуск по болест“.

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

в Пенсионния фонд на Руската федерация - 550 рубли;
в FFOMS - 127,50 рубли;
във Фонда за социално осигуряване - 72,50 рубли.

В програма Отпуск по болест, регистриран юли 2018 г, засяга изчисляването на застрахователните премии през текущия месец, като намалява базата за изчисление.

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

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

Необходимостта от представяне на актуализиран разчет на застрахователните премии

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

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

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

Пример 3

В този случай, за разлика от предишния пример 2, отрицателният размер на застрахователните премии в резултат на отмяната на командировка няма да бъде компенсиран от начисления. Въпреки факта, че поради начисленията на други служители, общата сума на застрахователните премии ще бъде положителна, в раздел 3 служителят ще остане отрицателна стойност и това е неприемливо. И следователно счетоводителят ще трябва да създаде документ Преизчисляване на застрахователни премии, преизчислете вноските за юни, генерирайте и изпратете актуализирано изчисление на Федералната данъчна служба.

Програмата 1C: Заплата и управление на персонала 8 автоматизира процеса на преизчисляване на застрахователните премии. Използване на услугата 1C-отчитанепървоначалните и уточняващи калкулации за застрахователни премии се генерират автоматично. Решението за изготвяне на уточняващо изчисление обаче остава на счетоводителя. След като анализира последствията от регистриране на документ, който променя изчисленията в периода, за който вече е подаден отчет, счетоводителят или преизчислява застрахователните премии за предходния период, или изчислението автоматично се извършва през текущия месец.

От редактора. В статията прочетете за механизма, внедрен в 1C:Enterprise 8 за проверка на контролните съотношения за изчисляване на застрахователните премии, който взема предвид данните от изчисленията на корекцията.