Обработка меняет суммы в документах Перечисление НДФЛ в бюджет по улучшенному алгоритму на заданный период.
Алгоритм распределения уплат взят у //infostart.ru/public/118152/
Обработка меняет суммы в документах Перечисление НДФЛ в бюджет по улучшенному алгоритму на заданный период.
При этом не надо изменять конфигурацию. С доработкой по комментариям от 15/03/2013
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Обработка меняет суммы в документах Перечисление НДФЛ в бюджет по улучшенному алгоритму на заданный период.
Перейти к публикации
Да, сказать по честному уже сом переделал, другую обработку под себя, и где то вышли недоплаты у кого то переплеты. теперь разбираюсь.
Честно говоря очень полезна данная обработка. все для разумного уравнения расчетов. Так что наши благодарности за труды.
Автору спасибо, сегодня буду тестировать!
Спасибо, нужная обработка
Спасибо, очень полезная обработка, не всегда у организации есть возможность полностью уплатить налоги и тогда при формировании НДФЛ возникает проблема правильности распределения сумм, а эта обработка позволит уменьшить эти проблемы.
Все получилось как в сказке… Спасибо и ПЛЮС
и конечно спасибо новому алгоритму 🙂
Спасибо завтра на работе как раз опробую 😉
Спасибо большое и 13% и 35% распределились ровно так как нужно.
Небольшой нюансик :).
Процедура Сформировать() стр. 400 я вставил проверку на документ помеченный на удаление.
Если Док.ПометкаУдаления()=1 Тогда
Продолжить; //[+] serpent, 14.03.2012
КонецЕсли;
иначе… обработка и их пытается пересчитать
(9)Согласен. Вставил в модуль.
Улучшенный алгоритм — понятие очень абстрактное и относительное. Насколько я понимаю, вся проблема с уплатой возникает, когда заявленные к уплате суммы за месяц расходятся с фактически начисленными (удержанными), откуда и возникают недоплаты (переплаты). Единственный оптимальный алгоритм вижу в разбиении крайних платёжек по месяцам на 2, для погашения недостачи по предыдущему месяцу. Собственно, как и в платёжках по пенс.взносам. Сомневаюсь, что машина сделает это за операратора. Хотя, в принципе, можно и это обыграть, но это довольно громоздко, и вряд ли здесь реализовано.
(11) Boroda,
Разбиение непросто крайних платежей, а этот аванс или недоплата будут качевать из месяца в месяц, пока не произойдет оплата налок сучетом аванса или недостачи.
Тоже поддерживаю данный вариант
(12) По-моему тут проще, кочевать ничего не будет. Одна платёжка с номером, допустим, 255 от 29.03.2012 общей суммой на 10000р., разбивается на две: одна с периодом марта, скажем, на 8225, а другая с периодом апреля на 1775р. И эта вторая сумма должна уже будет учтена в апрельских платежа. Крайняя платёжка апреля, аналогично, разбивается на две… Или Уже майская должна будет погасить задолженность за апрель, а осталоьная её часть остаться в мае.
Но это надо делать или руками, или перетаскивать платёжки из бухгалтерии, программно сравнивая их с начисленным/удержанным НДФЛ, и разбивая описанным выше способом.
(11) ну, даже если просто учесть промежуточные платежи (которые не учитывает стандартный) — это уже улучшение. и даже если перечисляешь тик в пык, по стандартному алгоритму получаешь постоянные болты
(13) разбиение на месяцы абстрактно и не совсем соответствует идеологии НДФЛ. например, можно 02.02.12 перечислить НДФЛ за февраль, а 14.02.12 — за январь. налоговый период — год, а правило, которое нужно соблюдать — не путать налоговые периоды, и перечислять НДФЛ не позднее дня выплаты дохода
(13) Boroda,
из опыта работы…
Расчетчики чухаются(начинают) разбираться с правильно разнесенным НДФЛ только к концу года. Стоит в начале года оплатить сумму с небольшим авансом(не важно по какой причине) и придеться переделывать все документы т.е.:
начислили 1000 — перечислили 1050
в следующих месяцах начисленное равно перечисленному, вот Эти «50-00 руб» и придеться кидать из месяца в месяц. до того момента пока за какой-то месяц не будет перечисленно на 50 рублей меньше
(13),(16) Попробуйте — там затронутая вами проблема была решена изначально.
(14)»по стандартному алгоритму получаешь постоянные болты» — по причине того, что распределение идет по периоду действия и коэфф. распределения «даже если перечисляешь тик в пык» почти всегда отличен от 1, хотя для «тик в пык» должен быть =1. Поэтому и предлагается () распределять НДФЛ по периоду регистрации.
(17) «Поэтому и предлагается (и,более того, требуется) распределять НДФЛ по периоду регистрации. » ну, во-первых, там конкретно про отпускные говорится, поэтому в общем случае данное утверждение неверно (например, бывают перерасчёты (в т.ч.НДФЛ) за прошлый нал.период).
во-вторых, у 1С в обоснование своей позиции по отпускным тоже есть ссылки на письма минфина, т.е. вопрос по-прежнему остаётся спорным
(18) А платите Вы НДФЛ по методике 1С (НДФЛ собранный по периоду действия) или, условно назову, по методике Минфина (НДФЛ собранный по периоду регистрации)? Мысль проста: при полной уплате у вас база распределения должна совпадать с суммой НДФЛ перечисленного, а иначе и имеем «постоянные болты» в виде «кудрявого» регистра по НДФЛ.
Для интереса выведите себе переменную ВсегоУдержано из процедуры ЗаполнитьТаблицуНалогов модуля формы документа ПеречислениеНДФЛвБюджет и посмотрите как она у Вас соотносится с перечисленной суммой за месяц.
(20)Так какую же сумму НДФЛ вы перечисляете «по методике НК РФ» — собранную по периоду действия или по периоду регистрации? И если первое, то где её берете?
Спасибо.
Спасибо за программу. сейчас буду ее опробовать.
(20)
К сожалению в 7-ке это не работает, т.к. справочник «Виды доходов» штатными средствами не редактируется, но даже при редактировании не удастся исправить код дохода 2012 так, чтобы он в регистре и справке выглядел как 2012.
В 7-ке нужно «выкорчевывать» упоминание 2012 из самого кода, там где это происходит напрямую, «в лоб». Благо мест таких не много.