Софтуерният продукт 1C: Заплата и управление на персонала 8, както подсказва името, е предназначен за управление на персонала и отчитане на разплащанията със служители на предприятието. Той има широки възможности, използвайки които е възможно да се организира управлението и счетоводството на сетълменти с персонал в предприятие от всякакъв размер и с помощта на голямо разнообразие от видове начисления и удръжки.
Тъй като програмата е гъвкава при настройване на различни счетоводни параметри, работни графици, видове изчисления, както и начини за отразяване на заплатите в счетоводството, е необходимо да се обърне специално внимание на настройката на програмата и попълването на всички документи за персонал и сетълмент и анализи във всеки документ. На практика има много грешки, свързани с непознаване на характеристиките на конфигурацията. Най-често се откриват грешки при изчисляване на заплати или генериране на публикации, които по-късно ще бъдат качени в 1C: Счетоводство 8 или 1C: Счетоводство 7.7. За да избегнете евентуални грешки е необходимо да обърнете специално внимание на първоначалните счетоводни настройки в програмата, а именно:
- директория "Организационни подразделения" - директорията се попълва автоматично чрез разтоварване от "1C: Счетоводство 8", като се посочват необходимите параметри ("За качване в нова информационна база"). Ако директорията се попълва ръчно, е необходимо да се обърне внимание на съответствието на имената и кодовете на нейните елементи с имената и кодовете на директорията „Организационни подразделения“ в счетоводната програма 1C;
- справочник "Разходни позиции" - също се попълва автоматично при зареждане на данни от 1C: Счетоводна версия 8 или 7.7. Необходимо е да се провери наличието на разходни пера "Плащане" и "Данъци и такси";
- директорията "Номенклатурни групи" трябва да съответства на директорията със същото име в 1C: Счетоводна версия 8 или 7.7;
- справочник "Методи за отразяване на заплатите в счетоводството" - справочникът съдържа списък на възможните записи, използвани при отразяване на заплатите в регулираното счетоводство.
Какви грешки възникват най-често при работа с програмата? Е, първо, това е формирането на „неправилни публикации“. За да се избегне подобна ситуация, е необходимо да се погрижите за настройките за публикуване и предварително да зададете на всеки служител определен начин за отразяване на заплатите в регулираното счетоводство. Така че можете да изберете начин за отразяване на заплатите по следните начини:
- задайте конкретен метод на цялата единица. Директория "Подразделения на организацията", раздел "Отчитане на заплатите";
- задайте метод за отразяване на заплатите на служител или списък на служителите. За това се използва документът „Въвеждане на информация за отчитане на доходите на служителите“;
- задайте конкретен метод за отразяване на заплатите за конкретно начисляване или приспадане. Необходимо е да посочите необходимото осчетоводяване в полето "Метод на отразяване в счетоводството" в раздела "Счетоводство и UTII".
Второгрешка в класацията на най-популярните - неправилно изчисляване на средните доходи за отпуск по болест или заплащане за отпуск. Причините за тази грешка може да са различни, но най-често това се дължи на факта, че някои суми не попадат в основата за изчисляване на средната печалба. Тази ситуация се коригира чрез задаване на базата за изчисляване на средната печалба (в менюто "Предприятие" - "Настройка на ведомост" - "Средна печалба"). В табличния раздел „Основни изчисления“ трябва да добавите вида на изчислението, което трябва да се използва при изчисляване на средната печалба.
третопо популярност грешката е включването / невключването на определени видове изчисления в основата за изчисляване на UST или данък върху доходите на физическите лица. За да се предотврати или коригира такава грешка, е необходимо да се провери настройката на конкретно начисляване, което погрешно подлежи или не подлежи на посочените данъци. В раздела "Данъци" в прозореца за редактиране на вида на начисляването има съответните полета - "PIT" и "UST, вноски в пенсионния фонд".
"грешно"плащането за непълен месец работа се изчислява в документа „Заплати за служители на организации“. Така наречената грешка може да възникне, когато работният график е зададен неправилно. Необходимо е да проверите броя на работните часове според работния график и в зависимост от ситуацията или да коригирате графика (ако грешката е в графика), или да въведете индивидуален график за този служител (ако служителят не е ходил на работа в съответствие с работния си график). Ако документът "Разписание" не е въведен, тогава по подразбиране се счита, че служителят е работил през всички работни дни в съответствие с работния график.
"грешно"генерира се график за време. Първото нещо, което трябва да направите, когато възникне такава ситуация, е да проверите дали производственият календар е попълнен правилно. Производственият календар, подобно на много други конфигурационни обекти, е гъвкав и лесен за използване. При необходимост работният ден може да се прехвърли към уикенда, а уикендът - към работния ден. След проверка на производствения календар се проверява наличието на всички записи на персонала и правилността на тяхното попълване.
Как можете да проследите грешка и да намерите документ или ръководство, в които трябва да направите промени?За да се анализира пълнотата на изчисленията на заплатите, се използва отчетът „Анализ на начисленията към служителите на организациите“. Отчетът ви позволява да проследявате съответствието на начислените суми със сумите, използвани при изчисляването на UST, данъка върху доходите на физическите лица и формирането на транзакции.
За да се анализират всички начисления и удръжки за всеки служител, е удобно да се използва „Разплатна ведомост в свободна форма“. Отчетът дава възможност да видите начисленията и удръжките за всеки служител не само в общи суми, но и в контекста на видовете изчисления.
За анализ на начислените данъци и вноски се използва справката „Анализ на начислените данъци и вноски“, в която освен начислените данъци се посочват плащанията, включени в данъчната основа за изчисляване, и плащанията, които не подлежат на облагане.
В допълнение към изброените се използват и отчетите „Регистър на начисленията“, „Регистър на счетоводството за изчисления на заплатите“, индивидуални карти на UST и OPS.Лесно е да се види, че всички тези грешки са резултат от невнимание и неправилно попълване на документи или настройка на съответните директории и видове изчисления. Ето защо, когато работите с програмата, се препоръчва да се обърне достатъчно внимание на необходимите настройки, правилното формиране на първични документи, както и да се обърнете към справочна литература, помощ на програмата и дискове с поддръжка на информационни технологии.
В информационните бази на платформата 1C могат да възникнат много различни грешки:
нарушаване на логическата/физическата цялост на базата данни, потребителски грешки, "крив" код на разработчици и много други.
Може да има много причини: светлината беше изключена и нямаше непрекъсваемо захранване или петък вечерта беше успешна и потребителят вече не може да си спомни какво е правил в понеделник.
Първо, струва си да зададете няколко изясняващи въпроса на потребителя:
1) Издания на платформа/конфигурация.
2) Пълен текст на съобщението за грешка. Потребителите имат неприятния навик да не четат изцяло такива съобщения и може би те съдържат препоръка за отстраняване на неизправности.
3) Преди колко време се е случило и при какви обстоятелства се появява. Невъзпроизводими грешки, които не сме виждали преди, едва ли ще успеем да коригираме.
4) Възниква ли, ако стартирате 1s от друг компютър / от друг потребител? Това ще ни даде храна за размисъл – дали изчистването на кеша, коригирането на разрешенията или изчистването на потребителските предпочитания може да помогне.
Сега малко за самите грешки и как да ги разрешите.
Общ:
Някои грешки възникват при използване на нелицензиран софтуер (windows, 1C и др.).
Често срещан пример е счупена платформа. Един от пачовете хаква конкретна версия на платформата, така че след като инсталирате нова версия на платформата и се опитате да влезете в базата данни, можете да видите прозореца „Няма намерен безплатен лиценз“.
Ако срещнете грешката за първи път - може би някой вече я е срещал -
потърсете в Google, може би някой вече се е сблъсквал с това и е решил проблема и няма да губите допълнително няколко часа от времето си.
Пускането на конфигурации трябва да бъде актуално (на първо място, за конфигурации, от които се подава регулирано отчитане), не без причина линията за консултации почти винаги предлага първо да се актуализира, а след това да се търси по-нататък.
Текуща версия на платформата - всяка конфигурация има описание коя версия на платформата се препоръчва за работа с тази конфигурация.
Технологичният дневник ви позволява да регистрирате всички събития на 1C:Enterprise (или част с помощта на филтър).
Можете да прочетете за него.
!!!ВАЖНО
Преди всякакви действия с базата - направете архивно копие!
Ако базата данни не се отвори в конфигуратора - копирайте папката с базата данни и изпълнете всички операции върху копието!
1) Базата данни изобщо не се отваря нито в потребителски режим, нито в конфигуратора.
- Най-бързото нещо, което можете да направите, е да изчистите временните файлове (изтрийте базата данни от списъка с бази данни и се свържете отново)
Това действие няма да изтрие временни файлове (кеш), но ще създаде нова папка за временни файлове на база данни, можете да изтриете файлове:
В Windows 7 в C:\Users\UserName\AppData\Roaming\1C\1Cv8x
В Windows XP C:\Documents and Settings\Username\Application Data\1C\1Cv8x
- Можете също да опитате да получите достъп до базата данни от друг потребител.
- Ако базата данни е файлова, тогава си струва да стартирате помощната програма за тестване на физическата цялост на базата данни chdbfl. Намира се в папката:
C:\Program Files (x86)\1cv8\8.x.x.xxx\bin\chdbfl.exe
- Ако базата е sql-та, тогава тестване с помощта на sql.
- Ако нито едно от двете не помогне, тогава можете да актуализирате платформата (вижте под коя платформа работи версията)
- Ако не се случи нищо от горното, можете да използвате програмата Tool_1CD.
2) Ако базата отиде в дъмп при стартиране.
- Деактивирайте хардуерното ускорение на графичната карта:
- Отворете свойствата на дисплея. Това може да стане чрез контролния панел или просто като щракнете с десния бутон върху произволно място на работния плот, където няма прозорци и икони, и изберете елемента от контекстното меню „Свойства“.
- В прозореца за настройки на дисплея, който се отваря, отидете в раздела „Настройки“ и щракнете върху бутона „Разширени“.
- В прозореца със свойства на графичната карта, който се отваря, отидете в раздела "Диагностика".
- Преместете плъзгача „Ускорение“ в най-лявата позиция („няма“) и щракнете върху „Приложи“ или „OK“. Хардуерното ускорение е деактивирано. Промените ще влязат в сила след рестартиране на системата.
- Отворете контролния панел (Старт - Контролен панел).
- Намерете и отворете елемента Екран.
- В лявата част на прозореца, който се отваря, щракнете върху връзката „Настройка на настройките на екрана“.
- В прозореца, който се отваря, щракнете върху връзката „Разширени опции“.
- Отидете в раздела „Диагностика“ и щракнете върху бутона „Промяна на настройките“.
- В прозореца, който се отваря, преместете плъзгача в най-лявата позиция ("не") и щракнете върху "OK". Ако UAC е активиран, ще трябва да потвърдите, че промените са разрешени от потребителя. Хардуерното ускорение е деактивирано. Промените ще влязат в сила след рестартиране на системата.
В Windows 7 в някои случаи бутонът Промяна на настройките ще бъде сив. В този случай не можете да деактивирате хардуерното ускорение, тъй като видеокартата и нейният драйвер не поддържат манипулиране на хардуерно ускорение.
- Ако антивирусът е Kaspersky, можете да опитате да деактивирате самозащитата и да преименувате файловете kloehk.dll и mzvkbd3.dll в папката Kaspersky. (Грешката възникна при по-стари версии на 2011 г., но все още се появява от време на време)
- Проверете дали версията/конфигурацията на платформата съвпада.
- Опитайте да получите достъп до базата данни от друга платформа.
3) Базата се отваря в конфигуратора, но не иска да влезе в потребителски режим.
- Почистване на временни файлове
- Опитайте се да влезете като друг потребител
- chdbfl / sql тестване
- Тестване и коригиране на информационната сигурност:
В конфигуратора Администриране-Тестване и корекция - отметки в зависимост от ситуацията. - Опитайте да създадете друг потребител с пълни права и да влезете от него.
- Опитайте да прехвърлите на друг компютър и отворете там, може и нещо от компютъра.
4) Когато някое действие изхвърля кода в конфигуратора.
- За да проверите, струва си да изчистите кеша.
- Ако не помогна, тогава най-вероятно грешка в кода - това е особено вярно за нестандартни и самостоятелно написани конфигурации, но понякога се среща и в типични.
Ако конфигурацията не е типична, тогава или актуализацията се е объркала, или разработчикът, който е финализирал конфигурацията, не е предвидил всички възможности за потребителски грешки - безупречно (ако е възможно!).
Ако е типично, тогава може би има грешка в изданието.
Във всеки случай си струва да преминете през дебъгера и да видите какво не е наред.
5) Под един потребител ви позволява да правите нещо, под друг не.
- Настройки на потребителските права.
- Потребителски настройки.
- Изчистване на кеша.
6) От единия компютър влиза, от другия не.
- Проверете дали изследователят вижда базата данни - може би папката с базата данни не е споделена.
- Изчистване на кеша.
- Влезте като друг потребител.
7) Направих / не направих нищо, но всичко се развали за мен
- Ако могат да ви кажат точно какво „не са направили“ и кога, можете да използвате
- дневник със селекции и може би ще разберете какъв е проблемът.
- Дневникът може да бъде намерен в конфигуратора:
- Администрация - регистрационен дневник.
Или в потребителски режим - местоположението зависи от конфигурацията.
8) Няма достатъчно памет.
Имах случай, дойде клиент, той казва, когато месецът е затворен, грешката „Няма достатъчно памет“ се срива. Заех се с този проблем. Мислех, че е лесно, първо добавих RAM - грешка. Беше 2 гига, стана 4, но пак 1с не стигат. Променен размерът на файла за пейджинг - грешка, преинсталирането на системата (инсталиран Windows 7) даде само временен резултат, около седмица. Опитах всичко. След известно време се намери решение.
Решение
На клиентския компютър стартирайте команден ред като администратор, въведете следното там:
BCDEdit /задаване на увеличениеuserva xxxx- вместо xxxx напишете количеството виртуално адресно пространство в мегабайти, т.е. Колко памет ви е необходима за стартиране на приложения? По подразбиране е 2 гига. Като цяло в 32-битовите операционни системи се разпределят 4 гигабайта: 2 за приложения и 2 за нуждите на самата ОС. Избрах 3000 (т.е. CDEdit /set increaseuserva 3000 ). Възможно е обаче системата да е бъгова. Особено ако имаш 2 гига RAM, като мен. Това е за семейство операционни системи Windows Vista, 7, Windows 2008.
За Windows XP \ Windows 2003 пишем
/3GB /serva=xxxx (xxxxв MB в диапазона 2048 - 3072) във файла boot.ini, препоръчителните максимални стойности userva 2900-3030.
9) Елементите на формата се припокриват един с друг и са в грешна позиция.
- Изчистване на кеша.
10) DBMS грешка вътрешна грешка на компонент dbeng8
- Грешката е свързана с разликата в кода на различните версии на платформата, когато потребителите се опитват да използват версията на файла. За версията клиент-сървър контролът се осъществява при стартиране и работата с различни версии на платформата е принципно невъзможна.
Решение: надстройте до най-новата версия на всички работни станции.
Ако не помогне, направете следното:
- Тестване и фиксиране
11) Грешка в платформа 8.3.4.428
- Във версия 8.3.4.428 на платформата 1C:Enterprise беше открита критична грешка, която възниква по време на преструктуриране на данни. Тази грешка е локализирана и ще бъде коригирана в следващата версия на платформата.
12) Конфликт на заключване при изпълнение на транзакция:
Microsoft OLE DB доставчик за SQL Server: Не може да продължи сканирането с NOLOCK поради движение на данни.
HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, състояние=3, сериозност=C, естествено=601, ред=1
„Как да проверя (възстановя) базата данни на MS SQL Server с помощта на сървърни инструменти
Проверката на логическата цялост трябва да се извършва с редовни средства на 1C: Enterprise (Тестване и коригиране на информационната сигурност). Ако такава проверка е неуспешна, трябва да проверите физическата цялост на базата данни с помощта на MS SQL. За да проверите целостта с помощта на MS SQL, трябва да изпълните следната команда:
Код:
DBCC CHECKDB("",REPAIR_REBUILD)
Преди да изпълните тази команда, базата данни трябва да бъде настроена на режим "един потребител":
Код:
sp_dboption "","един потребител",true
В процеса на изпълнение на DBCC CHECKDB могат да бъдат открити грешки и някои може да бъдат коригирани незабавно. Ако грешките останат, тогава очевидно те не могат да бъдат възстановени без загуба на някои данни. В този случай трябва да изпълните DBCC CHECKDB с параметъра REPAIR_ALLOW_DATA_LOSS (преди стартиране е препоръчително да направите копие на файловете на базата данни).
Код:
DBCC CHECKDB("",REPAIR_ALLOW_DATA_LOSS)
След като стартирате DBCC CHECKDB, трябва да запомните да се върнете към нормален режим (излезте от режим „един потребител“):
Код:
sp_dboption "","single user",false" (Взето от )
Разбира се, списъкът далеч не е пълен, така че ще се радвам, ако бъде допълнен в коментарите.
Много от вас вече са преживели важни промени. От януари 2018 г. поддръжката на "1C: Payroll and HR 8" издание 2.5 е преустановена. Ето защо 1C препоръчва на всички потребители да направят прехода към версия 3.1 възможно най-скоро.
Каним ви да се запознаете с типичните грешки, както и техните решения, които са идентифицирани от нашите специалисти:
1. Открити са грешки в прехвърлените документи в новата информационна база
Това се дължи на факта, че тези грешки не бяха коригирани в старата конфигурация. За да коригирате тези грешки, трябва да се върнете към предишната конфигурация, да премахнете всички грешки и да качите отново документите в новата информационна база.
2. В ЗУП 3.1 е прехвърлен дълг, който не съществува
Грешката се състои в това, че в базата, от която е направен преходът, са създадени платежни документи, но атрибутът за изплащане не е зададен. За да коригирате тази грешка, трябва да изтриете този запис във вече прехвърлените данни или да зададете флага за изплащане в оригиналната информационна база и да качите отново.
3. След разтоварване новата информационна база се претоварва с ненужни документи и справочници.
Тази грешка възниква поради грешен избор на метода на прехода. В големите организации пълната миграция зарежда много остаряла информация. Ако представлявате доста голяма организация с голям брой служители, тогава втората опция за прехвърляне е подходяща за вас - не пълна. За да разрешите тази грешка, се препоръчва да се върнете към началния етап и да изберете правилния метод за миграция.
In general, there is an opinion in accounting circles that once upon a time, data voluntarily (coincident, oddly enough, with the desire of an accountant) freely roamed from one information base to another, but evil programmers introduced St. George's Day and the transition began to be carried out only once a year at the beginning of the tax period, and then, through a gradual curtailment of rights, the data completely forgot how to be transferred at the will of the accountant ...
Не трябва да разубеждавате счетоводния отдел, че подобни заблуди нямат място в техните глави. Но можете (и вероятно трябва), преди да направите независим трансфер, да се запознаете с функциите и грешките, идентифицирани по време на прехвърлянето от Zeke 7.7 V ЗУП 8 , а именно:
1). на първо място, трябва да актуализирате конфигурациите на изходната и целевата бази данни (силно не се препоръчва да изтегляте данни през мрежата) и може да се изненадате къде грешки като „Индексът не е в границите на списъка със стойности“ ;
2). първото изчисление след превода на заплатите намерени удвоени суми за данък върху доходите на физическите лица (и не във всички бази данни - модел беше разкрит само когато периодът на фактуриране не е затворен в 7.7, т.е. ние го прехвърляме през юли, а юни не е затворен - през юли има удвояване) - в този случай е по-лесно да нулирате прехвърлените данни за данъка върху личните доходи чрез Операции - Документи - Прехвърляне на данни;
3). също така не са прехвърлени данни за служители, чиито регистри за данък върху доходите на физически лица са били водени преди 2011 г. под формата на 1-NDFL, а по-късно в данъчния регистър за данък върху доходите на физическите лица - в този случай ръчно въвеждане на документа „Счетоводни корекции за данък върху доходите на физическите лица, застрахователни премии и единен социален данък“, който също може да се използва за въвеждане на първоначални салда и възстановяване на счетоводството при прилагане на програмата;
4). непълнотата на производствения календар не е грешка по време на прехвърлянето, но този нюанс често не се взема предвид по време на първата заплата след прехвърлянето;
5). при извършване на сертификат във формуляра 2-NDFL се генерира грешка и документът не е изпълнен поради факта, че реквизитът „Адрес на физическо лице извън Руската федерация“ не е празен (запетаята трябва да бъде премахната), въпреки че в 7.7 адресът в страната на пребиваване не е попълнен;
6). издава доклада "Структура на дълга на организациите". дългосрочен дълг на служителите , селищата за които са затворени в Zik (на един от добре познатите форуми 1c причината беше посочена с неправилно плащане с ръчно посочване на сумата при уволнение, а не чрез изчисляване на пълното плащане), и оттогава. тези суми не са вложителят, тогава съответните записи в регистъра се изтриват от документите „Прехвърляне на данни“;
7). никога не копирайте документи, автоматично генерирани от обработката на трансфера, за да създадете документи, отразяващи факта на плащане на заплатата (плащането няма да се появи във ведомостта за заплати).
следва продължение...))
Грешки при попълване на 6-NDFL в 1C ZUP 8.2 (2.5)
Отворете универсалния отчет с условно форматиране:
Избираме раздел за търсене на грешки 2 от формуляр 6 - данък върху доходите на физическите лица:
След като зададете подходящите настройки, универсалният отчет ще покаже грешки, при които датата на дохода не съвпада с датата на удържане на данъка за доходи, различни от заплата. За доходи от заплата той проверява датата на дохода дали принадлежи към края на месеца или не. Той също така ще подчертае отрицателния удържан данък върху доходите на физическите лица.
Коригиране на грешки при попълване на 6-данък върху доходите на физическите лица в 1C 8.2 ZUP 2.5
Опитахте ли вече да попълните формуляра 6-NDFL във вашата база данни 1C ZUP 2.5? Достатъчно е да направите грешка веднъж, тъй като счетоводството на данъка върху доходите на физическите лица буквално се „срива“ и можете да забележите това само чрез формиране на 6-данък върху доходите на физическите лица.
Забравих да коригирам планираната дата на плащане
Получена е грешка от универсалния отчет - данъкът е удържан по-рано от получаването на дохода, това е случаят, когато са забравили да коригират планираната дата на плащане:
Как да поправя тази грешка? Отваряйки формуляра, можете да видите, че в нашия пример това е (Romashkina):
Нека преминем документа, ще се върнем към грешките. Грешката не е коригирана, датата на получаване на дохода е 28.01.2016 г.:
Отиваме в раздела за плащане и коригираме датата на получаване на дохода за 27.01.2016 г., след което го правим отново:
Грешката обаче не изчезва, което се вижда и във формуляра 6-NDFL:
Трябва да се помни, че раздел 2 от формуляра 6-NDFL се основава на удържан данък и удържаният данък се записва в платежния документ. За да коригирате напълно грешката, трябва да прехвърлите плащането отново:
След предприетите действия грешката беше напълно коригирана. В справка 6 - данъкът върху доходите на физическите лица е коригиран на 27.01.2016 г. и доходът е "свит" на датата на получаване от регистъра на доходите с данъчния регистър:
Коригира планираната дата на плащане на дохода, но забрави да коригира датата на данъка върху доходите на физическите лица
Да вземем за пример един документ. Обезщетението за отпуск по болест е начислено за януари 2016 г. с дата на плащане 05.02.2016 г. Всъщност надбавката е изплатена заедно със заплатата на 04.02.2016г. При изплащане на заплати при начисляване на отпуск по болест датата на изплащане на дохода беше коригирана от 04.02.2016 г., но в раздела за данък върху доходите на физическите лица те не бяха коригирани:
защо стана така Тъй като доходът беше отразен на датата 04.02.2016 г., тъй като коригирахме документа в основния формуляр „Болничен лист“, а сумата на данъка в раздела „Данък върху доходите на физическите лица“ беше отразена на датата 05.02.2016 г. Програма 1C изправя тази "кривина".
След осчетоводяване на платежния документ ще бъде отразен запис в регистъра на данъка, удържан при източника „Разплащания по ДДФЛ с бюджета“:
От регистъра на данъка, удържан при източника, данните автоматично се въвеждат във форма 6 - данък върху доходите на физическите лица:
За да коригирате грешката, е необходимо в документа „болничен лист“, в раздела за данък върху доходите на физическите лица, да коригирате датата на правилната 02/04/2016 и да публикувате документа:
След като грешките бяха коригирани, във формуляр 6 - данък върху доходите на физическите лица всичко също беше попълнено правилно:
За да не се налага да търсите и коригирате грешки, използвайте правилния подход при поддържане на регистри за данък върху доходите на физическите лица. а именно:
- Преди да изплатите доход, проверете и, ако е необходимо, редактирайте планираните дати за плащане в документите за начисляване (не забравяйте за раздела за данък върху доходите на физическите лица).
- Контролирайте размера на удържания данък върху доходите на физическите лица след всяко плащане.
- Преди приключване на месеца проверете съответствието на планираните дати за плащане с действителните
Нарушена е последователността на документите
И последно, за объркването с датите. За 99% от потребителите на 1C ZUP 2.5 удържаният данък върху доходите на физическите лица и датите в раздел 2 на формуляра за 6-данък върху доходите на физическите лица не работят. Това се дължи на факта, че отчитането на удържания данък върху доходите на физическите лица в 1C ZUP 2.5 (за разлика от новата версия на ZUP 3.0) е „скрито“ от очите на потребителя, изчислението се извършва автоматично при осчетоводяване на документи, така че резултатът зависи, наред с други неща, от последователността на провеждане.
Например, служител е начислен, всъщност надбавката е изплатена на 04.02.2016 г. В същото време датата на документа е оставена тази, в която е въведен:
Тогава те натрупаха ваканция:
Извършваме документа за плащане на ваканция от 27.01.2016 г.:
В регистъра на удържания данък върху доходите на физическите лица е регистрирано удържането на данък от обезщетения за болнични и са насложени следните документи:
Трябва да се върнете назад и да коригирате датата на обезщетенията за датата на плащане - 02/04/2016:
Датата на документа трябва да съвпада с планираната дата на плащане, тогава ще има много по-малко проблеми с хронологията на документите.
Връщаме се към платежния документ и препращаме документа:
Контролираме регистъра на удържания данък "Разчети с бюджета за данъка върху доходите на физическите лица". Добре.