Відсьогодні розпочинається тестування програми на базі оновлених бібліотек. Нагадаємо, що в користуванні поки що перебувають версії на базі бібліотек RunTime8. Відповідно, усі наступні версії будуть випускатися на RunTime9. Якщо на робочому місці поряд з АС-Зарплата встановлено АС-Фінплан, АС-Харчування або УМка (не дуже старих версій), то проблем з оновленням не буде жодних. Якщо ж встановлено лише АС-Зарплата, потрібно буде встановити відповідний пакет бібліотек RunTime9. Його можна взяти з будь-якого інсталяційного диску програм АгроСофт або завантажити з цього сайту.
На наступний рік заплановано модернізацію програми в бік розширення функціональності. В зв'язку з цим, просимо усіх бажаючих залишати в даному розділі Форуму власні побажання щодо розвитку проекту "АС-Зарплата". Тобто, хочемо почути, що ж реальні користувачі дійсно хочуть бачити або змінити у програмі.
Чекаємо на пропозиції!
До уваги усіх користувачів: на даний час зафіксовано помилку формування документів з вибіркою "пенсіонери". Заявку про виправлення прийнято на опрацювання і незабаром вийде нова версія програми АС-Зарплата з виправленням цієї ситуації.
В зв'язку з цим просимо поки не використовувати вказаний фільтр. Він не працює в жодному документі, тому не потрібно зайвий раз перевіряти Просто зачекайте нової версії.
До уваги Tublikarnya та інших користувачів АС-Зарплата, кого турбують повідомлення програми про підозрілі розрахунки
Нагадуємо, що програма містить модуль автоматичної діагностики даних, що видає свої результати у протоколи. Модуль складається з двох частин і, відповідно, може показувати два протоколи: помилок та зауважень.
Логіка діагностики полягає у перевірці даних перед закриттям розрахункового місяця. В ідеалі перед переходом на наступний місяць не повинно бути жодних повідомлень після діагностики. Але допускається наявність зауважень. "Зауважувальні" повідомлення лише звертають увагу користувача на приведення даних до рекомендованих значень. Тобто, причини цих зауважень не порушують цілісність та коректність даних розрахунку заробітної плати. А ось закривати місяць із помилками не можна, оскільки це на 90% призведе до порушення цілісності розрахунку. Простіше кажучи, архів минулого періоду з помилками не буде відповідати друкованим формам, сальдо тощо поточного періоду.
А тепер до суті питання. Повідомлення програми про підозрілі розрахунки є ЗАУВАЖЕННЯМ. А сенс цього зауваження у тому, щоб попередити користувача про нарахування/утримання розрахункового листка, що розповсюджуються на період більший 3 попередніх/наступних місяців порівняно з поточним. У вказаних межах, дійсно, допускаються коригування заробітної плати за минулий період або нарахування відпусток/лікарняних за майбутній період. Якщо ж знаходяться значення, що виходять за межі (+-)3 місяців - це сигнал до перевірки. Адже зазвичай така ситуація виникає лише в результаті механічної помилки користувача, коли випадково виставляється надто далекий період часу.
Таким чином, користувач, теоретично, може взагалі не звертати уваги на зауваження. Але ми рекомендуємо все-таки перевіряти усі повідомлення діагностики. Це набагато зменшує шанси отримання помилок методологічного характеру.
Цього року склалась досить унікальна ситуація, коли Держбюджет прийнято майже в середині року, причому він впливає на ключові значення для розрахунку заробітної плати, починаючи з 01.01.2010р. Ось і виходить, що поточний розрахунок заробітної плати міститиме масові перерахунки, що належатимуть періоду більшому 3 минулих місяців. І діагностика чесно попереджатиме користувача про це об'ємним протоколом зауважень про підозрілі розрахунки. Це може й дещо неприємно психологічно, але доведеться змиритися.
Діагностику даних можна запускати вручну і вона автоматично безумовно запускається перед самим переходом на наступний місяць. Та є додаткове налаштування програми, яке вмикає автоматичний запуск діагностики перед формуванням будь-яких звітно-довідкових форм. Ця функція допомагає уникнути ситуації друку документів на фактично помилкових даних, якщо перед цим не було запущено перевірку даних вручну. Оскільки такі документи (наприклад, оборотна відомість, свод по видах оплат, форма 5 тощо) формуються лише на завершальному етапі розрахунку заробітної плати, то незручностей не повинно бути. Але, якщо, з якихось причин, доводиться багато разів підряд формувати сводні форми і постійні зауваження дратують, можна й вимкнути автоперевірку перед друком. Та, в такому разі, на користувача лягає більша відповідальність за коректність тих самих документів, оскільки можна пропустити важливі зауваженя чи навіть помилки, які виявляться лише перед фактичним закриттям місяця, коли вже може бути пізно їх виправляти (здійснено виплату заробітної плати).
Висновки:
1) зрозумійте ситуацію із зауваженнями у поточному місяці правильно, перевіривши перед закриттям періоду, чи усі вони "нормальні";
2) якщо дратують зауваження перед друком сводів, спробуйте потерпіти і все-таки слідкувати за повідомленнями, щоб не пропустити хоча б помилок;
3) якщо сили волі не вистачає, можете вимкнути діагностику перед друком, але виявіть максимальну увагу при остаточному формуванні сводів для складання звітів, виплати заробітної плати тощо.
Сьогодні стало відомо, що Пенсійний фонд України готує зміни до порядку формування свого щомісячного звіту. Офіційних документів ще немає, але вже є проект та навіть свіже оновлення ПЗ "Бест-звіт плюс" 8.89.
У проекті документу про внесення змін йдеться про те, що існуючий Порядок формування звіту не передбачає механізму коригування сум заробітку (доходу) застрахованих осіб за попередні періоди. Тому, для відображення сум донарахування заробітної плати найманим працівникам за січень-квітень 2010 року, пов’язані з прийняттям Закону, проектом постанови правління передбачається використовувати код типу нарахувань 9 (9 – суми донарахувань заробітку (доходу) за січень-квітень 2010 року, пов’язані з прийняттям Закону України «Про Державний бюджет на 2010 рік») в таблиці 7 додатка 4 до Порядку.
Суми донарахувань заробітку (доходу) за січень-квітень 2010 вносяться окремо до поля відповідного місяця .
Даний код типу нарахувань дозволяє вносити за період січень-квітень 2010 року як додатні, так і від’ємні значення. Суми страхових внесків із заробітку (доходу) до реквізиту 14 таблиці 7 додатка 4 до Порядку для коду типу нарахувань 9 не вносяться.
На даний час приймання звітів призупинено і всі очікують офіційного підтвердження. Безперечно, мета майбутніх змін - справедлива, оскільки покликана хоч якось врегулювати проблему коректного зарахування працівникам страхового стажу. Але бухгалтерам, які ще не встигли відпочити після титанічної праці із перерахунків заробітної плати з початку року, доведеться знову братися до роботи, щоб відобразити ці перерахунки у звіті за новими правилами.
Щойно ситуація проясниться остаточно, будуть внесені зміни в АС-Зарплата. А поки потрібно чекати новин.
Повний текст проекту та приклади заповнення таблиць 6 і 7 міститься у прикріпленому файлі.
metodist приєднав файл: pfu_9code.zip
Після численних звернень користувачів та марних намагань отримати офіційне підтвердження було вирішено внести зміни до АС-Зарплата для можливості експорту в АРМ-ЗС перерахунків за січень-квітень 2010р. Оновлення можна знайти у відповідному розділі завантажень на нашому сайті, або через автоматичну систему оновлень АС-Зарплата.
Зміни грунтуються на інформації, представленій у листі №9396/05-01 від 02.06.2010р. і реалізовані без офіційної підстави в умовах, що дані зміни не порушують існуючих алгоритмів, а додають нові можливості.
Підкреслюємо, що даний документ є внутрішнім і адресованим лише начальникам ГУПФУ. Тобто, сам лист описує пропоновані зміни, але, фактично, у "Порядок формування та подання страхувальниками звіту щодо сум нарахованих внесків на загальнообов'язкове державне пенсійне страхування органам ПФУ" змін не вносить. А саме згаданий Порядок регламентує форму та зміст звіту і, формально, подання всупереч йому - заборонено.
Більш того, виявлено, що останнє оновлення ПЗ Бест-звіт 8.89 хоча й дозволяє працювати із кодом 9 у таблиці 7, але містить друкований бланк цієї таблиці звіту, у якому відсутня інформація про даний код. До того ж, при заповненні реального звіту виникають закономірні "непорозуміння", коли таблиця 6 містить від'ємні або рівні 0 значення (оскільки підсумок перерахунку може й не бути додатнім чи може належати працівнику, який не мав заробітку у звітному місяці). Деякий досвід подання попередніх звітів дозволяє остерігатися того, що звіт із такими значеннями не приймуть.
Схоже, ПФУ в черговий раз ставить завдання без чіткого розуміння як його реалізації, так і всіх наслідків ситуації...
Просто зачекайте нової версії.