1с перерахунок. Виправлення та перерахунки заробітної плати. Витіснення за періодом дії

Від інших – наприклад, премія може визначатися сумою окладів у період. При цьому можлива ситуація, коли оклад буде змінено вже після того, як розраховано премію. За умовчанням такі ситуації платформа не контролює. Якщо розробник вважає за необхідне це відслідковувати, то потрібно скористатися спеціальним підпорядкованим об'єктом регістру розрахунку - Перерахунок:

Записи перерахунків зберігаються у окремій таблиці. Вони не гарантують того, що залежний регістр потрібно точно перерахувати, але є сигналом про таку потенційну необхідність.

У загальному випадку записи таблиці перерахунків містять поля:

• об'єкт перерахунку (документ-реєстратор, дані якого потрібно перерахувати)
• вид розрахунку - посилання вид розрахунку з Плану видів розрахунків, визначеного для даного регістру розрахунку

Записи можна зберігати і більш детально, у розрізі одного або кількох вимірів цього регістру розрахунків. Наприклад, перепроводився заднім числом реєстратор нарахування заробітної плати по всьому відділу; при цьому зміни були лише за співробітником Івановим. Додавання до Перерахунку вимірювання Співробітник дозволить це відстежити. При цьому вимірювання Перерахунку потрібно пов'язати з вимірюванням регістру розрахунку:

Дані таблиці перерахунків формуються автоматично, якщо у плану видів розрахунків виставлено властивість Базовий період . Якщо властивість не виставлено, то формування записів відповідає розробник.

Питання 14.41 іспиту 1С: Професіонал з платформи. Дані про перерахунки...

1. не є записами регістру розрахунку
2. є записами регістру розрахунку
3. є записами регістру перерахунку
4. є записами таблиці фактичного періоду дії

Правильна відповідь перша, вони взагалі зберігаються в окремих таблицях.

Питання 14.42 іспиту 1С: Професіонал з платформи. У вікні властивостей вимірювань "Перерахунку" на закладці "Зв'язок" у властивості "Вимірювання регістру" вказується...

1. вимірювання базового регістру, при зміні даних якого слід перерахувати поточний запис регістру
2. вимірювання поточного регістру, записи з яким слід перерахувати за зміни даних базових регістрів
3. вимірювання базових регістрів, при зміні даних яких слід перерахувати поточний запис регістру

Правильна відповідь друга. Сам перерахунок необхідний відстеження необхідності актуалізації записів поточного регістру.

Питання 14.43 іспиту 1С: Професіонал з платформи. Таблиця "Перерахунку" заповнюється рядками, кожна з яких є...

1. набір відомостей про вид розрахунку та документ-реєстратор запису регістру розрахунку, яку потрібно перерахувати. Також у таблиці будуть присутні вимірювання перерахунку
2. набір відомостей про вид розрахунку та документ-реєстратор запису регістру розрахунку, який потрібно перерахувати
3. набір відомостей про вид розрахунку, номер рядка документа-реєстратора та сам реєстратор запису регістра розрахунку, який потрібно перерахувати. Також у таблиці будуть присутні вимірювання перерахунку
4. немає правильних відповідей

Перша відповідь вірна, розбір вище.

Питання 14.45 іспиту 1С: Професіонал з платформи. Виберіть правильну відповідь:

1. У процесі роботи з перерахунками розробник може "не звертати уваги" на відомості, які надає система у таблиці перерахунку, тобто відмовитись від перегляду результатів розрахунку
2. Принцип роботи перерахунків у системі "1С:Підприємство 8" є "повідомчим"
3. Розробник конфігурації не може керувати процесом перерахунку записів регістру розрахунків, система все робить автоматично
4. Правильно 1 та 2 твердження

Правильна відповідь четверта - перерахунок лише відстежує потенційну необхідність зміни залежних даних.

Питання 14.46 іспиту 1С: Професіонал з платформи. Для одного регістру розрахунку...

1. може підтримуватися лише один перерахунок
2. можуть підтримуватися лише три перерахунки різної структури
3. підтримується будь-яка кількість перерахунків різної структури

Правильна відповідь третя, немає проблем додати до регістру розрахунку будь-яку кількість підлеглих об'єктів. Перерахунок, структура їх ніяк не контролюється.

Питання 14.57 іспиту 1С: Професіонал з платформи. Періодичність ведення розрахунків – місяць. У регістрі розрахунку зроблено відповідні налаштування. Для виду розрахунку Оклад як витісняє зазначений вид розрахунку Відрядження. 01.03.14 в інформаційну базу було введено інформацію з окладу, проте розрахунок зроблено не було. 20.03.14 в інформаційну базу було введено та розраховано відрядження. 30.03.14 було запущено розрахунок за окладом. Чи будуть при розрахунку окладу враховані дані про відрядження? Чи потрібно робити перерахунок відрядження?

1. Враховані будуть, але відрядження доведеться перерахувати
2. Враховано будуть, перерахунок відрядження не потрібний
3. Враховані не будуть. Потрібно скасувати розрахунок відрядження і заново розрахувати обидва види розрахунку
4. Враховані не будуть. Щоб правильно зробити розрахунок, оклад та відрядження повинні перебувати в одному документі

Перерахунок не потрібний, запис про відрядження всередині місяця.

У цій статті розглянемо теоретичні основи роботи з регістрами розрахунку, а також здійснимо розрахунок заробітної плати співробітника пропорційно до кількості відпрацьованих годин.

Теорія

Реєстр розрахунку (РР)- об'єкт метаданих зміни, що служить для реалізації періодичних розрахунків у системі 1С. З очевидних областей застосування регістрів розрахунку можна назвати такі: розрахунок зарплати, розрахунок квартплати, розрахунок орендної платы.

По структурі регістри розрахунку схожі на регістри накопичення чи регістри відомостей. Вони як і регістри накопичення мають виміри, ресурси, реквізити, але принцип дії регістрів розрахунку абсолютно інший.

За своєю суттю виміру в регістрі накопичення служать « фільтром» у межах якого ми отримуємо дані з регістру накопичення. Як приклад, коли ми беремо "залишки" за регістром накопичення "Залишки товарів" у розрізі певної номенклатури або "зріз останніх" по регістру відомостей "Оклади співробітників" у розрізі певного співробітника. На відміну від регістру накопичення виміру в періодичному регістрі розрахунку служать для реалізації «(це коли протяжні в часі види розрахунку конкурують між собою на інтервалі періоду дії запису тобто як приклад, вид розрахунку відрядження витісняє вид розрахунку оклад за періодом дії) і «(це коли вид розрахунку премія залежить від виду розрахунку оклад за минулі періоди).

механізму витіснення за періодом дії«:

Тут ми бачимо, що вид розрахунку «Відрядження» має протяжність у часі та діє з 10 по 20 квітня, «Відрядження» зазначено як витісняючий вид розрахунку для виду розрахунку «Оклад». «Оклад» також має протяжність у часі та діє з 1 по 30 квітня. Так як «Відрядження» вказано як витісняючий вид розрахунку для виду розрахунку «Оклад» (має більший пріоритет, ніж оклад) і діє на період дії окладу, відбувається витіснення окладу відрядженням і формується «Фактичний період дії окладу». » це період дії окладу після витіснення відрядженням, у нашому випадку він складається з 2 періодів - з 1 по 9 квітня та з 21 по 30 квітня та в сумі становить 19 днів. Механізм витіснення за періодом дії працює лише для протяжних у часі розрахунків.

На малюнку вище графічно показано принцип « механізму залежності за базовим періодом«:

Припустимо, наприкінці квітня 2017 року ми хочемо нарахувати співробітнику премію у розмірі 10% від окладу. Як базові види розрахунку для премії зазначений оклад.

Але як базу для розрахунку премії ми візьмемо не весь місяць квітень, а лише інтервал з 10 по 20 квітня (11 днів). Розрахуємо базу для премії, оклад співробітника становить 60000 рублів, на місяць маємо 30 днів, денний оклад = 60000/30 = 2000 крб. Далі 2000 * 11 = 22000 руб. База до розрахунку премії становить 22000 рублів.

Розрахуємо премію: (22000/100) * 10 = 2200 руб. Премія у вигляді 10% від окладу становить 2200 рублів.

З регістром розрахунку тісно пов'язаний прикладний об'єкт метаданих «План видів розрахунку».

План видів розрахунку (ПВР)- об'єкт метаданих зміни, який у собі відомості про типи видів розрахунків і визначальний вплив різних розрахунків друг на друга.

Один план видів розрахунку може використовуватись у кількох регістрах розрахунку, але один регістр розрахунку неспроможна використовувати кілька планів видів розрахунку одночасно.

Регістр розрахунку є таблицею у якій зберігаються розраховані дані, а плані видів розрахунку зберігаються алгоритми розрахунку цих даних. Регістр розрахунку обов'язково повинен мати хоча б один документ реєстратор, який робить рух по регістру розрахунку (наприклад, нарахування зарплати).

Механізми розрахунку в системі 1С Підприємство влаштовані таким чином, що спочатку потрібно зробити записи в регістр розрахунку і після цього виконати розрахунок на основі цих даних. Наприклад, не можна розрахувати премію з урахуванням окладу доки цей оклад не записаний в регістр розрахунку.

Практика

Розглянемо докладніше регістри розрахунку практично:

Крок 1. Почнемо з плану видів розрахунку. План видів розрахунку необхідно створити перед створенням регістру розрахунку. План видів розрахунку створюємо перед регістром розрахунку оскільки перед створенням таблиці зберігання розрахованих даних (тобто. регістру розрахунку) необхідно задати алгоритми розрахунку цих даних (тобто. план видів розрахунку).

Створимо план видів розрахунку «Основні нарахування». Відразу перейдемо на вкладку «Розрахунок». Тут ми відразу ж бачимо прапор. Використовує період дії«, при встановленні даного прапора всі види розрахунку, що входять до цього плану, будуть володіти протяжністю у часі(наприклад, Оклад, Відрядження), а також для даного плану видів розрахунку включається « механізму витіснення за періодом дії«. Якщо прапор «Використовує період дії» не встановлений, то види розрахунку не володітимуть протяжністю в часі (наприклад, Премія, Штраф) і «механізму витіснення за періодом дії» не діятиме. Також на цій вкладці є розділи «Залежність від бази» та «Базові плани видів розрахунку» - вони служать для реалізації « механізму залежності за базовим періодомАле про нього поговоримо пізніше. Поки залишимо "Залежність від бази" в режимі "Не залежить".

Створимо певний вид розрахунку "Оклад". На вкладці "Основне" все просто. Задаємо ім'я та код виду розрахунку.

Завдяки тому, що ми встановили прапор « Використовує період дії» у нас з'явилася вкладка « Витісняючіі включився механізм витіснення за періодом дії«.

На цій вкладці ми вказуємо види розрахунку, які витіснятимуть оклад за періодом дії (наприклад, Відрядження).

Примітка: у «Витискаючі» можна додати види розрахунку належать лише даному плану видів розрахунку.

Також є вкладка « Ведучі» - На ній вказуються види розрахунку при зміні яких повинен перераховуватись поточний вид розрахунку. Тут можна вказати і види розрахунку інших планів видів розрахунку. Наприклад, вид розрахунку «Оклад» є провідним виду розрахунку «Премія» тобто. при зміні окладу ми маємо перерахуватися і премія т.к. премія нараховується залежно від окладу. У разі вид розрахунку «Оклад» належить ПВР «Основні нарахування» використовує період дії, а вид розрахунку «Премія» належить ПВР «Додаткові нарахування» що не використовує період дії.

Крок 2. Створимо довідник «Графіки» зі структурою за замовчуванням. У довіднику «Графіки» зберігатимемо режими роботи співробітників (п'ятиденка, шестиденка тощо).

Крок 3.Також нам потрібен об'єкт у якому ми зберігатимемо Виробничий календар (робочі та вихідні дні). З цією метою використовуємо неперіодичний незалежний регістр відомостей.

Створимо неперіодичний незалежний регістр відомостей «Графіки роботи» з 2 вимірами «Дата» та «Графік» та ресурсом «Кількість годинників».

Завдяки регістру відомостей «Графіки роботи» ми зможемо нараховувати заробітну плату від окладу пропорційно до кількості відпрацьованих днів.

Крок 4.Створимо документ «Нарахування зарплати» зі структурою реквізитів, показаною нижче:

Реквізити:

Оперативне проведення ставимо значення «Заборонити»т.к. воно не має сенсу для механізму періодичних розрахунків у 1С - ні премію, ні оклад, ні штраф ми ніколи не нараховуємо в реальному часі.

Створимо форму документа з налаштуваннями за замовчуванням.

Крок 5. Нарешті ми дійшли до створення регістрів розрахунку.

Об'єкт метаданих регістр розрахунку розташований у гілці "Регістри розрахунку" конфігуратора.

Створимо регістр розрахунку «Основні нарахування». Налаштування регістру розрахунку розглянемо нижче:

1.У полі «План видів розрахунку» вказуємо ПВР «Основні нарахування», створений на кроці 1.

2. Ставимо прапор «Період дії» значення «Істина» т.к. ПВР, вказаний на кроці 1 має протяжністю у часі.

Після встановлення даного прапора у нас відразу ж стають доступні стандартні реквізити «ПеріодДії», «ПеріодДіїПочаток», «ПеріодДіїКінець» це означає, що види розрахунку реєструються в даному регістрі розрахунку також мають протяжністю у часіі в нас стає доступним механізму витіснення за періодом дії«.

P.S. Якщо вказати ПВР, що володіє протяжністю у часіу РР з прапором «Період дії» у значенні «Брехня», то даний ПВР працюватиме як ПВР, що не володіє протяжністю у часі.

3.Після встановлення прапора «Період дії» у значення «Істина» у нас стають доступні поля «Графік», «Значення графіка», «Дата графіка».

У полі "Графік" вказуємо регістр відомостей "Графіки роботи", створений на кроці 3.

У полі «Значення графіка» вказуємо ресурс «КількістьГодин» регістру відомостей «Графіки роботи».

У полі "Дата графіка" вказуємо вимірювання "Дата" регістру відомостей "Графіки роботи".

4.У полі «Періодичність» вказуємо значення «Місяць» це означає, що дані у регістр у нас будуть заноситися щомісяця.

Нижче представлена ​​структура метаданих регістру:

Прапор «Базове» у виміру впливає лише на продуктивність, його можна і не проставляти, але якщо поставити, то поле «Співробітник» буде проіндексоване.

Вимір «Співробітник» — він застосовується в « механізмі витіснення за періодом дії» та « механізм залежності за базовим періодом«.

Ресурс "Сума" - туди запишеться розрахована зарплата.

Реквізит «Графік» зазначений як реквізит, а чи не вимір регістру т.к. ні його, ні він нічого не витісняє — насправді довідкове поле. Важливо! Не забудьте заповнити поле «Зв'язок із графіком»у реквізиту «Графік», там має бути зазначений вимір «Графік» регістру відомостей «Графіки роботи», інакше розмір заробітної плати не буде розраховуватися.

Реквізит «Параметр» зберігатиме значення окладу.

Ось тепер, коли ми вказали зв'язок з РС «Графіки роботи», у нас буде розраховуватися заробітна плата співробітника пропорційно кількості відпрацьованих днів.

Як реєстратор вказуємо документ « Нарахування зарплатні«, Створений на кроці 4.

Крок 6. Робимо рухи з регістру розрахунку «Основні нарахування».

Повернімося до документа «Нарахування зарплати», створеного на кроці 4.

Опишемо обробку проведення у модулі об'єкта документа:

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

1С (Код)

Процедура ОбробкаПроведення(Відмова, РежимПроведення) // Регістр ОсновніНарахування Руху.ОсновніНарахування.Записувати = Істина; Рухи.ОсновніНарахування.Очистити(); ПеріодРеєстрації = Початок Місяця (Дата); Для кожного ТекРядокОсновніНарахування З ОсновніНарахування Цикл Рух = Рухи.ОсновніНарахування.Додати(); Рух.Сторно = Брехня; Рух.ВидРасчета = ТекСтрокаОсновніНарахування.ВидРасчета; Рух.ПеріодДіїПочаток = ТекРядокОсновніНарахування.ДатаПочатку; Рух.ПеріодДіїКінець = КінецьДня(ТекРядокОсновніНарахування.ДатаЗакінчення); Рух.ПеріодРеєстрації = ПеріодРеєстрації; Рух.Співробітник = ТекРядокОсновніНарахування.Співробітник; Рух.Графік = ТекРядокОсновніНарахування.Графік; Рух.Параметр = ТекРядокОсновніНарахування.Розмір; КінецьЦикл; КінецьПроцедури

Процедура ОбробкаПроведення(Відмова, РежимПроведення) // Регістр ОсновніНарахування Рухи. Основні нарахування. Записувати = Істина; Рухи. Основні нарахування. Очистити(); ПеріодРеєстрації = Початок Місяця (Дата) ; Для кожного ТекРядокОсновніНарахуванняЗ ОсновніНарахуванняЦикл Рух = Рухи. Основні нарахування. Додати (); Рух. Сторно = Брехня; Рух. ВидРасчета= ТекРядокОсновніНарахування. ВидРозрахунки; Рух. ПеріодДії Початок = ТекРядокОсновніНарахування. Дата початку; Рух. ПеріодДіїКінець=КінецьДня(ТекРядокОсновніНарахування. ДатаЗакінчення) ; Рух. ПеріодРеєстрація = ПеріодРеєстрація; Рух. Співробітник = ТекСтрокаОсновніНарахування. Співробітник; Рух. Графік = ТекРядокОсновніНарахування. Графік; Рух. Параметр = ТекСтрокаОсновніНарахування. Розмір; КінецьЦикл; КінецьПроцедури

Створимо тестовий документ та проведемо його:

Перейдемо до «Руху документа»:

Бачимо, період реєстрації встановився як початок місяця т.к. періодичність РР вказана "Місяць". Також бачимо, що заповнилися всі поля крім суми (ЗП ще розрахована).

Крок 7.Напишемо код розрахунку заробітної плати.

Створимо загальний модуль «Розрахунок» із такими прапорами:

У цьому загальному модулі у нас і відбуватиметься сам розрахунок.

Напишемо в модулі «Розрахунок» експортну функцію «Розрахувати нарахування»:

Оскільки ми заповнили в налаштуваннях РР «Основні нарахування» поля «Графік», «Значення графіка», «Дата графіка», у нас стала доступна віртуальна таблиця регістру розрахунку Графіка,у запиті до віртуальної таблиці нас цікавлять поля:

«КількістьГадинФактичнийПеріодДії»містить розраховану на підставі даних графіка кількість фактично відпрацьованих годин

«КількістьГадинПеріодДії»містить розраховану на підставі даних графіка кількість робочих годин у періоді розрахунку

Процедура розрахунку заробітної плати

1С (Код)

Процедура РозрахуватиНарахування (Реєстратор, Набір Записів) Експорт // Оклад Запит = Новий Запит; Запит.Текст="ВИБРАТИ | ЄNULL(ОсновніНарахуванняДаніГрафіка.КількістьГадинФактичнийПеріодДії, 0) ЯК ГодинФакт, | ОсновніНарахуванняДаніГрафіка.Параметр, | ніНарахуванняДаніГрафіка.НомерРядки |З |РеєстрРасчета.ОсновныеНачисления.ДанныеГрафіка(| = &Реєстратор |І ВидРасчета = &ВидРасчетаОклад) ЯК ОсновніНарахуванняДаніГрафіка"; Запит.ВстановитиПараметр("Реєстратор", Реєстратор); // Передаємо документ реєстратор щоб пошук виконувався тільки за поточним документом Запит. //Встановлюємо вид розрахунку оклад т.к. розраховуємо оклад Вибірка = Запит. Виконати (). Вибрати (); СтруктураПошук=Новий Структура; СтруктураПоиска.Вставить("НомерРядки",0); //Створимо структуру для пошуку даних для розрахунку за номером рядка Для кожного запису з набору записів цикл //цикл по набору записів поточного документа СтруктураПоиска.НомерРядки=Запись.НомерРядки; //заповнюємо номер рядка для пошуку Якщо Вибірка.ЗнайтиНаступний(СтруктураПошуку) Тоді //шукаємо у вибірці дані для розрахунку за поточним номером рядка Запис.Сума =? . Параметр); //Розраховуємо ЗП пропорційно відпрацьованим дням, в Параметр - поточний оклад КінецьЯкщо; Вибірка.Скинути(); //скинемо вибірку, потрібно щоб наступний запис набору записів робив пошук за вибіркою спочатку Кінець циклу; Набір Записів. Записати (Істина); //записуємо розраховані записи до бази, передаємо параметр Заміщати = Істина КінецьПроцедури

//Оклад Запит = Новий Запит; Запит. Текст="ВИБРАТИ | ЄNULL(ОсновніНарахуванняДаніГрафіка.КількістьГадинФактичнийПеріодДії, 0) ЯК ГодинФакт, | ОсновніНарахуванняДаніГрафіка.Параметр, | ЄNULL(ОсновніНарахуванняДаніГрафіка.КількістьГодинПеріодДії, 0) ЯК ЧасовПлан, | ОсновніНарахуванняДаніГрафіка.НомерРядки |З | РеєстрРозрахунки.ОсновніНарахування.ДаніГрафіка( | Реєстратор = Реєстратор

Добридень. Давненько мене не чути:) Сьогодні хочу прояснити особливості перерахунків у ЗУП 3.0 за минулі періоди. Ця стаття розповідає про те, як воно влаштоване всередині та, відповідно, Ви зможете контролювати цей процес. Адже напевно Ви стикалися з тим, що програма несподівано нараховує людині незрозумілі суми, сторнує їх, з'являються якісь різниці... а Ви цього і не хотіли, чи хотіли. а цього не сталося))

Почнемо. Перше – перерахунки відбуваються у момент, коли Ви вважаєте ЗП документом "Нарахування зарплати". Для цього в ньому передбачено закладку "Донарахування, перерахунки". Перше, що хочу Вам порадити: завжди перевіряйте дані у табличці "Донарахування, перерахунки" . Вони там можуть з'явитися без Вашого відома, а Ви й не зрозумієте, чому в розрахунках сума не та.

За ідеєю у шапці документа нас завжди попереджають у тому, що програма збирається когось перерахувати чи треба виконати перезаповнення, т.к. когось не перерахували.

Звідки програма знає, кого мені треба перерахувати і за якийсь місяць?

Вона визначає це, виходячи з Ваших дій. Чи перепровели документ заднім числом? Програма переглянула співробітників, які були у цьому документі та зафіксувала їх список. Чи ввели документ виправлення (наприклад, виправили табель за минулий місяць)? Усіх із цього табеля програма запам'ятала і цей місяць буде перераховано. Впливають практично всі документи як кадрові, і розрахункові. При цьому програмі не важливо вплинуло Ваше торкання документа на зарплату чи ні.

Припустимо, Ви зайшли в прийом на роботу і написали там коментар, після чого перепровели документ. Ні окладу, ні дати прийому, ні посада... нічого не чіпали. Але програма не знає, навіщо Ви перезаписали проведений документ минулого періоду, вона не є телепатом, вона просто зафіксувала цього співробітника.

Друга порада (він же перший секрет): через "усі функції" залізте в регістр відомостей "Перерахунок зарплати". Не полінуйтеся та залізте! Залазьте туди перед кожним розрахунком зарплати та після кожного зворушеного заднім числом документа.

Цю пораду багато бухгалтерів сприймають як те, що у них з'являється нова робота, якої в них і так вистачає. Але не лазія туди, Ви не зрозумієте логіки роботи, а якщо програма буде для Вас як чорна скринька, то Ви з нею не подружитеся. Дружба починається з розуміння внутрішнього світу друга! Якщо Вам начхати на внутрішній світ оппонента, то він Вам не друг.

Отже, ви залізли? Чудово. Як правило там порожньо і немає жодного рядка, але як тільки Ви чіпате щось заднім числом, тут з'явиться запис, що містить співробітника і місяць, який треба перерахувати.

Третя порада: якщо Ви не згодні з наміром програми перерахувати співробітника, зітріть рядок з цього регістру.

1. Як з'являються рядки, Ви вже зрозуміли? чудово.

2. При заповненні документа "Нарахування зарплати" та його проведенні виходячи з рядків у регістрі проводиться перерахунок та заповнення таблички "Донарахування, перерахунки".

3. Перераховані співробітники забираються з регістру і він стає порожнім.

4. У разі скасування проведення документа "Нарахування зарплати" рядки повертаються на місце, щоб при повторному перезаповненні все вставало на місця.

Четверта порада (можливо це виправлять): перед перезаповненням документа "Нарахування зарплати" розпроведіть його!

Виходячи з алгоритму, після проведення документа регістр очищується. Якщо його перезаповнити без розпровіду, то програма не дізнається, кого треба перерахувати, і таблична частина з перерахунками буде порожньою. Це було вірно для релізу 21. У 22-му ще не встиг перевірити.

Ще нюанс, якщо Ви в документі натисніть за списком людей до перерахунку, то відкриється форма списку регістру відомостей"Перерахунок зарплати".І там теж буде кнопка "видалити" один запис.

П.С. (важливий)

Приводом для цього розслідування послужили нескінченні перерахунки при перенесенні початкових даних з Бухгалтерія 3.0. Вам при переході будь-кому доведеться торкнутися всіх прийомів і перекладів)) після цього зітріть весь вміст регістру " "Перерахунок зарплати", інакше отримаєте перерахунок всього і вся за всі роки. Початок роботи в ЗУП 3.0 з перенесенням даних з Бухгалтерії

Ось що сталося в демо-базі під час переведення одного прийому на роботу. А при переході 1С Бухгалтерії 3.0 до 1С ЗУП 3.0 ви перепроведете все, що тільки можна:

Це все, питання в коментарі і не бійтеся програми, її треба розуміти і вона відплатить Вам за це любов'ю.

Багато програмісти 1С ніколи не стикалися у своїй практиці з компонентом «Розрахунок», тому, коли їм доводиться складати іспити на Фахівця з Платформи 8.0, де в кожному завдання є завдання по складним періодичним розрахункам, виникають складності, насамперед складності розуміння.

Спробуємо розібратися з цією компонентою 8.0. Замість вирішувати різні завдання на розрахунок спробуємо розібратися з цією компонентою так, щоб можна було вирішити будь-яке завдання з розрахунку. Вивчивши цей посібник, ви зрозумієте, як влаштовані та працюють регістри розрахунку.

Наприклад будемо використовувати каркасну конфігурацію, яка встановлюється на іспитах.

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

Що таке розрахунки

У принципі, кінцевий продукт розрахунку зарплати – це набір записів регістру розрахунку виду:

Співробітник	Період	Вид розрахунку	Результат	Дані	Коментар
Вимірювання	Службовий	Службовий			Реквізит

Значення в колонці «Дані» відображають базовий оклад працівника (згідно з трудовим договором), але ця сума може бути збільшена преміями, зменшена штрафами та невиходами тощо, тому реальна сума до виплати заноситься після виконання розрахунку у колонку «Результат». У цьому полягає розрахунок. Сума по колонці «Ресурс» для цього співробітника - належна йому зарплата.

Таким чином, регістр розрахунку - по суті набір записів, за структурою схожий на оборотний регістр накопичення. Просто для виконання складних розрахунків для нього вказуються додаткові налаштування, які дозволяють будувати багато віртуальних таблиць для регістру розрахунку, хоча, по суті цей регістр - просто набір записів, вказаних на малюнку.

Кожен запис регістру розрахунків відноситься до певного виду розрахунку та періоду часу.

Види розрахунків

Кожен запис видів розрахунку має службовий реквізит – вид розрахунків.

Вид розрахунків можна уявляти як елемент особливого довідника типу «План видів розрахунків» - він також має реквізити, табличні частини, зумовлені і заведені користувачем елементи. У системі може бути кілька таких довідників.

Наприклад заведемо план видів розрахунку Основний і у ньому визначені види розрахунку оклад, премія, невихід, відрядження.

Види розрахунку використовуються функціонально у тому, щоб відбити вплив записів регістру розрахунку друг на друга. Але скорочено говорять про вплив видів розрахунку один на одного:

Вид розрахунку	Опис	приклад
За базовим періодом	Результат розрахунку залежного періоду залежить від результату базового періоду. Якщо результат базового періоду зміниться, результат залежного періоду потрібно перерахувати.	Премія залежить за базовим періодом від окладу.
Витіснення за періодом	Період дії залежного періоду витісняє період дії базового періоду, таким чином у базового періоду з'являється фактичний	Невихід впливає фактичний період дії окладу.
Провідні розрахунки	Розрахунок залежить від провідного розрахунку, але з прямо побічно, тобто. розрахунок залежить від базового розрахунку Б, а розрахунок Б залежить від базового розрахунку, отже А побічно залежить від, тобто. А залежить від провідного розрахунку В. Справді, при зміні розрахунку може змінитися Б і отже може змінитися А. Система автоматично не відстежує такі складні залежності, тому потрібно вказувати які розрахунки є провідними.	Премія залежить з урахуванням від окладу, але й побічно залежить і від невиходу.

В силу такого впливу період дії запису регістру розрахунків ділиться на чотири періоди:

Період	Опис
Період реєстрації	У період зареєстровано подія, тобто. зазвичай, коли введено документ.
Період дії	У період діє подія, тобто. якого періоду належить подія.
Базовий період	Має сенс лише періодів, мають базовий період - визначає інтервал базового періоду.
Фактичний період дії	Якщо період дії витісняється іншими видами розрахунків, фактичний період дії складається з кількох періодів, коли цей вид розрахунку фактично діє.

Період реєстрації визначається одним числом - початком періоду, що відповідає періодичності регістру розрахунку. Навіть якщо ми встановимо на це службове поле іншу дату, він все одно заміниться на початок періоду. Інші періоди задаються двома полями - початком і кінцем периода.Фактический період дії - це набір періодів, т.к. може складатися з кількох інтервалів дат.

Графіки часу

У системі є можливість пов'язувати дані з регістрів розрахунку з графіками часу, щоб у будь-якому періоді можна було отримати кількість робочих годин.

Графік часу - це простий регістр відомостей, один вимір якого зберігає дату, інший пов'язується з виміром регістром розрахунку, а з ресурсів використовується для обліку часу.

Вимірювання, яке зв'язується з регістром розрахунку зазвичай носитьзміст «вид графіка».

Дата	Вигляд графіка	Значення
11.01.05 пункт	П'ятиденка
11.01.05 пункт	Шестиденка
12.01.05 сб	П'ятиденка
12.01.05 сб	Шестиденка

Чому використовується вимірювання дата, а не періодичний регістр відомостей? Все дуже просто – якщо 11 січня у п'ятницю по п'ятиденці у нас 8 робочих годин, то це ще не означає, що наступного дня у нас буде знову ж таки 8 робочих годин. Адже якби ми використовували періодичний регістр, значення наступного дня бралося б із попереднього дня за відсутності записів.

Таким чином, маючи певний період (фактичної дії, реєстрації, базовий період тощо), ми можемо автоматично отримати кількість годин за цей період за графіком.

Перерахунок

Перерахунок чимось нагадує межу послідовності. Так як у нас є залежні розрахунки, то при зміні їх базових та провідних розрахунків система має якось відзначити, що ми маємо перерахувати залежні розрахунки.

Для цього і є перерахунки.

Якщо ми розрахуємо базові записи, то система відзначить у перерахунках, що потрібно розрахувати залежні записи. Як тільки розрахуємо залежні записи, перерахунки очистяться.

По суті перерахунки – це список записів регістру розрахунку, які потрібно перерахувати.

Якщо в перерахунках не заводити жодного виміру, то при зміні базових розрахунків до списку перерахунку занесуться усі залежні записи.

Якщо ми заведемо вимір «Співробітник» у перерахунку, то при зміні базового розрахунку по співробітнику до перерахунків додадуться залежні записи тільки з цього співробітника.

Практичне завдання

Достатньо теорії. Спробуємо вивчити деталі практично. За основу візьмемо каркасну конфігурацію.

Постановка задачі:

Нехай премія задається фіксованим відсотком до окладу (за вирахуванням невиходів та відрядження).

Відрядження нехай оплачуються у подвійному окладі + фіксована сума виплат за кожен день відрядження.

Нехай за невиходи зі співробітника стягується штраф у розмірі половини окладу за період невиходу.

Хід виконання:

Початкова підготовка

Створимо новий план видів розрахунку "Основний".

Визначимо види розрахунку та залежності між ними:

	Базові	Витісняючі	Ведучі
Оклад		Невихід, Відрядження
Премія		Невихід, Відрядження	Оклад, Невихід, Відрядження
Відрядження
Невихід

Занесемо ці види розрахунку до плану видів розрахунку «Основний» і у властивостях видів розрахунку поставимо залежності згідно таблиці.

У регістрі розрахунку зарплати зробимо вимір «Співробітник» типу «Фізичні Особи» – щоб у регістрі був розріз аналітики по співробітникам.

У конфігурації вже є документ «Нарахування зарплати».

У ньому дві дати в шапці - «дата» та «період реєстрації», а також по дві дати «дата початку» та «датакінця» у кожному рядку.

Мається на увазі, що дата - це просто дата оформлення документа, період реєстрації вказує, за який місяць ми рахуємо зарплату, а дати в кожному рядку описують період дії кожного виду розрахунку.

Додамо в модуль документа початкову установку реквізиту «Дані» - до нього заноситимемо початковий оклад, встановлення періоду реєстрації, періоду дії та базового періоду.

Модуль документа виглядатиме приблизно так:

Для До кожного ТекРядокСписокЗ Список Цикл

// Регістр Розрахунки

Рух = Рухи .Расчеты.Додати();

Рух .= Брехня;

Рух .У ідРасчета = ТекРядокСписок.Вид Розрахунку;

Рух .ПеріодДії Початок= ПочатокДня ( ТекРядокСписок.ДатаПочатку);

Рух .ПеріодДіїКінець= КінецьДня ();

Рух .ПеріодРеєстрації = ПеріодРеєстрації;

Рух .БазовийПеріодПочаток= ПочатокДня ( ТекРядокСписок.ДатаПочатку);

Рух .БазовийПеріодКінець= КінецьДня ( ТекРядокСписок.ДатаЗакінчення);

Рух .З срудник = ТекРядокСписок.Співробітник;

Рух .Графік роботи = ТекРядокСписок.Графік;

Рух .Результат = 0;

Рух .Дані = ТекРядокСписок.Розмір;

Кінець циклу;

Реквізит Потрібен, щоб сторнувати записи (аналог мінуса).

Проставляємо вид розрахунку, дати наводимо до початку та кінця дня. Звичайно базовий період можна проставляти тільки у залежних за базою видів розрахунку, а дані можна проставляти тільки в окладу, але й так все працює.

Усі документи датуватимемо 20.01.2003, період реєстрації ставитимемо 02.01.2003 (спеціально вказую не початкові та кінцеві дані, тут це неважливо, все одно при записі в ПеріодРеєстраціїперетворюється на початок періоду 01.01.2003). Січень 2003 року використовуємо тому, що за цей період заповнені графіки робіт.

Заведемо перерахунок «Перерахунок», додамо до нього вимір «Співробітник», пов'язаний із виміром «Співробітник».

Граємо з перерахунками.

Для гри відкриємо консоль запиту - обробка ПроїзнийЗапит» у каркасній конфігурації. Створимо новий запит конструктором запиту, додамо туди віртуальну таблицю Перерахунки. Розрахунки., текст запиту буде таким:

ВИБРАТИ

РозрахункиПерерахунок.Про б'єктПерерахунку,

РозрахункиПерерахунок.,

РозрахункиПерерахунок.

З

РеєстрРозрахунки.Розрахунки.ПерерахунокЯК РозрахункиПерерахунок

Сформуємо три документи – першим нарахуємо оклад співробітникам А та Б. Співробітник А працює з 1 по 31 січня, Б працює з 1 по 20 січня. Другим нарахуємо премію співробітнику Б за період з 1 до 31 січня, третім призначимо невихід співробітнику А з 20 по 25 січня.

Граємо з фактичним періодом дії.

Створимо новий запит - цього разу до нього додамо дані таблиці РегістриРасчета.Расчеты.ФактическийПеріодДії.

Сформуємо запит та побачимо, що співробітнику А період дії окладу розбито на два періоди – з 1 по 19 та з 26 по 31 січня. Сподіваюся зрозуміло, що період було розбито на два, т.к. невихід витіснив оклад.

Думаю, механізми роботи регістру розрахунку прояснюються на очах.

Вивчаємо графіки.

Тепер спробуємо нарахувати зарплату за окладом співробітника.

Створимо новий запит щодо регістру розрахунку використовуючи віртуальну таблицю РегістриРасчета.Расчеты.ДанныеГрафіка. У цій віртуальній таблиці можна задати параметр - умова відбору записів, наприклад Співробітник=&ВибСпівробітникі ВидРозрахунку=&ВидРозрахункуі Графік=&ВидГрафіка.

Задамо в параметрах запиту конкретних співробітників, види розрахунку та графіків та подивимося, скільки годин виходить у результаті.

Колонка результату	Значення
ЗначенняПеріодДії	На який період дії в годиннику був запис у регістрі.
ЗначенняФактичнийПеріодДії	Скільки співробітник фактично пропрацював у годиннику
ЗначенняБазовийПеріод	Для окладу сенсу немає, для премії - кількість робочих годин у базовому періоді.
ЗначенняПеріодРеєстрації	Скільки робочих годин у періоді реєстрації (місяць січня)

Перерахунки становлять невід'ємну частину розрахунку зарплати. Відомості про лікарняні листи, відпустки або прогули працівників, що надходять до бухгалтерії з деяким запізненням, тягнуть за собою перерахунки зарплати і, відповідно, страхових внесків. Про відображення розрахунків та перерахунків страхових внесків в обліку та регламентованої звітності у програмі «1С:Зарплата та управління персоналом 8» редакції 3 розповідають експерти 1С.

При перерахунку заробітної плати виникає потреба у перерахунку страхових внесків. Крім того, причиною перерахунку внесків може бути і зміна тарифу протягом року або виявлення помилок, наприклад, невключення розрахунку до бази страхових внесків.

У цих випадках у бухгалтера виникають питання про необхідність, обов'язок та право подавати уточнені відомості до ІФНС.

Відповідно до пункту 1.2 Порядку заповнення розрахунку за страховими внесками, наведеним у Додатку № 2 до наказу ФНП Росії від 10.10.2016 № ММВ-7-11/551@, платник зобов'язаний внести необхідні зміни до Розрахунку та подати до податкового органу уточнений звіт, якщо виявились невідбиті або неповні відомості, а також помилки, що призводять до заниження суми страхових внесків, що підлягає сплаті.

Приймаючи рішення, чи подавати уточнений розрахунок, бухгалтер має відповісти на такі питання:

• чи всі відомості були відображені;
• чи були допущені помилки, і чи призвели вони до заниження суми страхових внесків до сплати.

Подання уточненого Розрахунку може бути обов'язком, правом та вимушеною необхідністю.

Уточнений Розрахунок страхових внесків

Обов'язок здати уточнений розрахунок виникає, якщо після подання звіту до ІФНС виявилося, що передано неповні або неправильні відомості про співробітників, або виявились помилки, що призводять до заниження суми страхових внесків до сплати.

Види поширених помилок, які потребують обов'язкового подання уточненого Розрахунку:

1. Співробітник не повідомив своєчасно про зміни у своїх особистих даних, та в ІФНС подано недостовірні відомості про нього у Розділі 3 Розрахунку.

2. Співробітник працював у підрозділі, який має право на застосування пільгового тарифу страхових внесків. Потім було переведено до підрозділу, де застосовується основний тариф страхових внесків. Інформація про переведення співробітника надійшла до бухгалтерії із запізненням. Розрахунок внесків було здійснено помилково за пільговим тарифом.

3. На етапі початкового налаштування програми «1С:Зарплата та управління персоналом 8» припустилися помилки, виключивши премію з розрахункової бази зі страхових внесків. Виправлення помилки призводить до донарахування внесків.

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

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

Розглянемо особливості перерахунку страхових внесків у «1С:Зарплаті та управлінні персоналом 8» редакції 3 на прикладах.

Приклад 1

Під час розрахунку страхових внесків для підрозділу Складзастосовувався пільговий тариф страхових внесків Резиденти техніко-впроваджувальної особливої ​​економічної зони(код тарифу "05"). Цей тариф передбачає у 2018 році відрахування до ПФР у розмірі 13%; у ФСС 2,9%; у ФФОМС 5,1%. Саме так і провадився розрахунок внесків для співробітниці В.С. Плющ. При щомісячному заробітку 10 000 руб. сума страхових відрахувань за місяць склала:

• в ПФР - 1300 руб.;
• у ФФОМС – 510 руб.;
• у ФСС – 290 руб.

Вказані суми були відображені у розрахунку зі страхових внесків за І квартал 2018 року.

Коли з'ясувалося, що підрозділ втратив право на застосування пільгового тарифу страхових внесків, то відповідно до листів ФНП Росії від 25.10.2017 №?ГД-4-11/21611@ та Мінфіну Росії від 18.12.2017 №?03-15-06/ 84443 виникла потреба уявити уточнюючий Розрахунок. Для його формування слід перерахувати страхові внески з новими ставками.

У картці Підрозділислід очистити поле Пільговий тариф страх. внесків. Тепер для підрозділу застосовується тариф, який використовується для організації та вказаний у картці Організаціїна закладці Облікова політика та інші налаштуванняза посиланням Облікова політикав полі Вид тарифу.

У Прикладі 1 для організації встановлено Основний тариф страхових внесків(код тарифу «01»), що передбачає у 2018 році ставки відрахувань: до ПФР у розмірі 22 %; ФСС 2,9%; ФФОМС 5,1%. Очевидно, що у ПФР «недоплачено» 9% внесків (22% - 13%), та змінився код тарифу.

У прикладі 1 для перерахунку внесків слід переглянути порядок обліку доходів. Для реєстрації порядку обліку доходів та перерахунку страхових внесків минулого періоду призначено документ (меню Податки та внески). На закладці Відомості про доходинеобхідно вручну уточнити усі доходи працівників. При цьому на закладці Обчислені внескиавтоматично буде здійснено перерахунок страхових внесків.

Внаслідок перерахунку страхових внесків співробітниці В.С. Плющ за щомісячного заробітку 10 000 руб. сума страхових відрахувань за місяць склала:

• в ПФР - 2200 руб.;
• у ФФОМС та у ФСС - сума не змінилася і склала, відповідно, 510 руб. та 290 руб.

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

Мал. 2. Титульний лист уточнюючого розрахунку страхових внесків за I квартал 2018 року

Право подання уточненого Розрахунку зі страхових внесків

Страхувальники можуть подати до інспекції уточнений Розрахунок, якщо виявили помилки, що призводять до завищення суми страхових внесків. Насправді при черговому розрахунку внесків у поточному періоді проводиться перерахунок, і результат відображається у звіті за черговий період. Варіанти ситуацій, що дозволяють подати уточнений Розрахунок:

1. Співробітнику нарахували зарплату за повний відпрацьований місяць. Розрахунок зі страхових внесків здали до ІФНС, але згодом з'ясувалося, що співробітник був на лікарняному або у відпустці власним коштом. Нарахування, яке не входить до бази для розрахунку внесків, замінило нарахування, що оподатковувалося страховими внесками, що призвело до переплати внесків.

2. Будь-які перерахунки нарахувань співробітника, що призводять до перерахунку страхових внесків у бік їхнього зменшення.

Приклад 2

При розрахунку зарплати за червень співробітнику С.С. Горбункову було нараховано:

• оплата по окладу – 7 500 руб.;
• оплата відрядження (за середнім заробітком) за червень - 2 500 руб.

Обчислено страхові внески за основним тарифом. У червні внески із зарплати С.С. Горбункова склали:

• в ПФР - 2200 руб.;
• у ФФОМС – 510 руб.;
• у ФСС – 290 руб.

Ці внески були сплачені та включені до Розрахунку за півріччя 2018 року. Поданий до бухгалтерії лікарняний лист на період 25.06.2018-30.06.2018 не створює причин для формування уточненого Розрахунку. Зареєстрований у програмі документ Лікарняний листсторнує нараховану раніше суму відрядження (рис. 3).

Мал. 3. Перерахунок відрядження у документі «Лікарняний лист»

Лікарняний лист надійшов до організації в липні. Це не є помилковою ситуацією та не призводить до недоплати страхових внесків. Оскільки сума, нарахована за лікарняним листом, страховими внесками не оподатковується, то виникла переплата внесків у розмірі:

• в ПФР – 550 руб.;
• у ФФОМС – 127,50 руб.;
• у ФСС – 72,50 руб.

В програмі Лікарняний лист, зареєстрований Липнем 2018, Впливає на розрахунок страхових внесків у поточному місяці, зменшуючи розрахункову базу.

Законодавчих вимог щодо подання уточненого Розрахунку в такій ситуації немає. Усі перерахунки відбуваються черговим періодом та відображаються у чергових звітах. Але при цьому організація має право уточнити звіт за півріччя і повідомити ІФНС про переплату, що відбулася, представивши уточнену.

Однак, до закінчення місяця не слід робити поспішних уточнень Розрахунку. Адже упродовж місяця реєструються різні документи. У якийсь момент документ Лікарняний листсправді може відсторнувати доходи минулого місяця, а за результатами розрахунку зарплати за місяць інший документ, наприклад, Нарахування зарплати та внесків, Проведе донарахування, що перевищують сторно-доходи минулого періоду. В результаті на суму сторно відрядження зменшаться доходи поточного місяця, ніяких мінусів за минулий місяць не залишиться, і звіт змін не покаже.

Необхідність подання уточненого Розрахунку зі страхових внесків

У ряді випадків, незважаючи на відсутність обов'язку за поданням уточненого Розрахунку, у страхувальника немає іншої можливості повідомити про свою переплату внесків, крім подання уточненки:

1. У співробітника внаслідок перерахунку внесків у поточному періоді утворюється від'ємна сума. Звіт з негативною сумою не може бути здано до ІФНС. Отже, вихід один – сформувати уточнений звіт за минулий період.

2. Співробітник працював на шкідливому виробництві. Страхові внески обчислювалися за додатковим тарифом. Інформація про переведення співробітника на роботу із звичайними умовами праці надійшла до бухгалтерії із запізненням. Внаслідок перерахунку неможливо зменшити обчислені внески за додатковим тарифом, адже нарахування працівника у поточному періоді вже не обкладаються внесками за додатковим тарифом.

Приклад 3

У цьому випадку, на відміну від попереднього Прикладу 2, негативна сума страхових внесків, що утворилася при сторнуванні відрядження, не буде компенсована нарахуваннями. Незважаючи на те, що за рахунок нарахувань інших працівників загальна сума страхових внесків буде позитивною, у Розділі 3 у співробітника залишаться негативні значення, а це неприпустимо. І тому бухгалтеру доведеться створити документ Перерахунки страхових внесків, перерахувати внески за червень, сформувати та подати до ІФНС уточнений Розрахунок.

Програма «1С:Зарплата та управління персоналом 8» автоматизує процес перерахунку страхових внесків. За допомогою сервісу 1С-Звітністьвихідні та уточнюючі розрахунки за страховими внесками формуються автоматично. Проте ухвалення рішення про підготовку уточнюючого Розрахунку залишається за бухгалтером. Проаналізувавши наслідки реєстрації документа, що змінює розрахунки в періоді, за який вже подано звіт, бухгалтер виконує перерахунок страхових внесків за минулий період, або розрахунок автоматично відбувається поточним місяцем.

Від редакції У статті читайте про реалізований у «1С:Підприємстві 8» механізм перевірки контрольних співвідношень розрахунку страхових внесків, який враховує дані коригувальних Розрахунків.