Как сверить АДВ-6-2 и РСВ-1 "с превышением" для разных отчетных периодов

[LoraK]

Знаю я одного программиста, который пишет набивалку ПФР для всей страны. Вот он как раз "чиста программист", не очень разбирается в той области, которую автоматизирует.
И в гоструктурах, к сожалению, это обычно правило, чем исключение.
В коммерческих структурах, как раз всё наоборот.

У такого программиста должен быть хороший разработчик (не знающий языка программирования, но обязательно хорошо разбирающийся в предметной области).
А на практике, да, чаще встречаются программисты, которые знают бухгалтерию больше бухгалтеров.

[LoraK]

Плохой алгоритм. Во-первых, ИС должны закрыться уплатой в первую очередь, чтобы не создавать "излишней социальной напряженности". Во-вторых, а если текущей уплаты не хватило даже на "солидар"? Все платят по разному, и не всегда вовремя.

Во-первых , из чего это следует? И при чем здесь социальная напряженность? Взносы с превышения не раскладываются на лицевые счета. А в остальном все по-честному: всем с одинаковым коэф-том, пропорционально начисленным взносам.

Во-вторых, это не наш случай (мы достаточно крупное предприятие, взносы все-таки платим). А если бы вообще уплаты не было?

В-третьих, я уже обосновала свою позицию. "Отдай обязательные платежи, а остальное - дели".

Словом, не убедили.

[Ирина55]

К сожалению, программисты часто при реализации учитывают только узкий участок бухучета и не "влезают" в бухучет в целом. Да, подчас узкий участок программист знает лучше бухгалтера, так как читает кучу законодательной информации. Но в общем подчас этого не достаточно. Или неудобно для программирования.

Простой пример. 1С проводит очень адекватные семинары, которые ведут их консультанты. Однако на вопрос, почему так построена программа, в которой подчас не учитываются базовые понятия бухучета, ответа один - разработчикам неудобно так программировать. Сейчас мы у себя начали переходить на 1С 8.2. Что-то очень удобно. Но вопросов - море, ответов на них нет, причем многие вопросы весьма принципиальные.

[Алексей К.]

в которой подчас не учитываются базовые понятия бухучета, ответа один - разработчикам неудобно так программировать. Сейчас мы у себя начали переходить на 1С 8.2. Что-то очень удобно. Но вопросов - море, ответов на них нет, причем многие вопросы весьма принципиальные.

Ирина, поделитесь опытом, какие например понятия не учитывают программы, например. Какие вопросы Вы считаете принципиальными. Без подробностей, просто идеология программ - всегда интересная тема. Сложная. В ней сложно отличать субъективные взгляды и объективные вопросы. Ваше мнение интересно. Спасибо.

[Ирина55]

Примеры по 1С.
Основное бухгалтерское понятие "ДОКУМЕНТ" не всегда возможно применить в реализованных в программах алгоритмах.
1. В 1С 8.2 "ушел" такой документ, как банковская выписка (в 7.7 он был). Тем не менее это документ, который выдается банком и бухгалтеру удобно, когда он есть.
2. Проводки 51-50. Сейчас идеология - проводка берется по кассовому документу, банковский документ вообще не заводится. Если деньги получают под разные основания, банк проводит разные расходы у себя разными списаниями, а кассовый документ (приходный ордер) один и "плодить" его нецелесоообразно (бухгалтер, работающий с банком, получил наличные и сдал кассиру по приходному ордеру). Документ должен заводиться каждый, а проводка формироваться одна (в 7.7 так и было). Можно завести документ, а в нем вручную удалить проводку, но это неудобно.
3. Неверно проводится приход/расход по кассе в документах от поставщиков - там вообще нет физлица, а есть только организация ФИО должно быть обязательно (это Порядок ведения кассовых операций, а в качестве подтверждающих документов должна быть Доверенность со своими реквизитами).

ПРОВОДКИ.
1. Практически невозможно при УСН вести рекомендованный Минфином упрощенный план счетов. Там вообще нет субсчетов, но программа не дает этого делать (на счет 76 проводки формировать нельзя, программа не дает этого сделать). Если взять какой-то субсчет как базовый, все равно формируются обороты по зачету авансов, которые практически задваивают оборотные ведомости. Да и при отражении в КУДиР возникают проблемы.
2. Жесткая работа с авансовыми субсчетами по 60 и 62 счетам, привязанная к дате документа. Это не всегда так, авансы есть авансы, не всякая предоплата есть аванс. Особенно при длительных взаиморасчетах с постоянными клиентами, когда покупатель периодически перечисляет определенные суммы, а продавец отгружает товар независимо от сумм оплаты, а потом выверяются взаиморасчетами. Такие взаимоотношения часто бывают у крупных организаций с поставщиками стройматериалов или ГСМ. Ведение субсчетов 60.01 и 60.02 не всегда оправдано (и не обязательно), подчас бухгалтеру и на ОСН удобнее вести субсчета 60 счета по группам товаров и услуг. Аналогично 62, 76. "Зачетные" проводки не дают возможности оценить приход-расход по счету в целом, так как все практически все проводки задвоены зачетом авансов. Кроме того, простой пример - услуги связи, интернета. В начале месяца поставщик услуг как правило выставляет счет за предыдущий месяц, вы его оплачиваете началом месяца (программа автоматически поставит 60.02, так как документа по подтверждению услуг еще нет). Но это никакой не аванс - это оплата потребленных услуг. И акт вам оформят чаще всего последним числом предыдущего месяца. В 1С автоматического зачета не произойдет, т.к. акт пройдет раньше платежа, потом придется править проводку по банку (а если эти проводки делают разные бухгалтера, это тем более не удобно).
3. Неудобна жесткая регламентация товары/услуги. Это не всегда можно разделить, особенно когда услуги надо отнести, например, на стоимость ОС или подобно. Причем программа сама "путается" в этих понятиях - я поняла эту проблему и перестала пытаться пользоваться функцией "ввести на основании", хотя это было бы удобно.
4. Опять же жесткая регламентация видов договоров - с поставщиком, с покупателем, жесткая привязка видов договоров к приходным/расходным документам. Конечно, взаимозачеты сейчас не очень поощряются, но на практике взаимоотношения между хозяйствующими субъектами бывают разные, плодить несуществующие договора - это неверно.
5. Очень редко в программах в блоках зарплаты можно встретить счета, отличные от 70. Тем не менее гражданско-правовые, авторские договора, договора по аренде отслеживаются на 76 счете (это не зарплата, они искажают в балансе 70 счет), но по ним идут начисления НДФЛ, страховых взносов. Можно было бы вести определенные группы физлиц, у которых счетами дебета/кредита были бы субсчета 76 счета вместо 70.

Это то, что я вспомнила сразу. Конечно, из всех этих ситуаций так или иначе выйдем, но подчас обосновывать все это грамотным проверяющим из различных ведомств весьма непросто.

Много вопросов возникает и на сайте, причем опять же подход такой, какой удобен программисту (ни в коем случае не хочу ничего плохого сказать - я сама приктически всю жизнь программистом отработала, "перешагнуть" через это и встать "на сторону" бухгалтера очень сложно).
В частности по уплате страховых взносов. ЛЮБЫЕ страховые взносы платятся за объект страхования и привязываются к нему. Понятно, что в том бардаке, который творится в ПФР, голову свернешь. Но тем не менее я считаю категорически неверным "закрывать" уплату по каким-то сотрудникам, которая реально еще не перечислялась.
Постоянный дур-дом - отразить в налоговом регистре выплаты по НДФЛ. Ведь только зарплата должна учитываться по концу месяца, а все остальное (например, матпомощь) - по дате выплаты. Но это же невозможно формализовать и провести по всему учету. Аналогично весь сыр-бор по удержанию налога, в какой момент это происходит и как учесть ограничение 50% от выплаченной суммы.
А, например, правильно отразить в бухгалтерском и налоговом учете договор ГПХ с этапами работ, которые закрываются актами, но выплата денежных средств в соответствии с договором производится в другие сроки (например, договор на 4 месяца, расписан график работ, каждый этап закрывается актом в установленные сроки, перед началом работ выплачивается аванс 20% от суммы, через 2 месяца - еще 30%, по концу работ - все остальное).
Думаю, практически нет программ, которые реализуют это верно. Тут уж обижайся-не-обижайся, но это так. Я слышала, что в некоторых европейских странах все законы проходят государственную экспертизу по возможности формализации. Нам до этого далеко.

[OlegTT]

Интересно, а как ПФР будет администрировать накопительную часть если будут приняты эти поправки?
http://www.glavbukh.ru/news/14835

[Ирина55]

Ну если бы у ПФР хватило ума делить на страховую и накопительную самостоятельно по заявлению застрахованного лица, а страхователь вообще не делил бы взносы, то все было бы нормально.
Мечты, мечты ...

[VinnieThePOOH]

У такого программиста должен быть хороший разработчик (не знающий языка программирования, но обязательно хорошо разбирающийся в предметной области).

Это называется постановщик задачи. Хороший постановщик понимает как предметную область, так и методы автоматизации, в том числе умеет рисовать процессы, назначать в них контрольные точки и так далее.

Это довольно высокий уровень квалификации, и часто, говоря, что человек программист - имеют ввиду именно такого специалиста.

Что касается разработчика ПФР, набивалкой которого недовольны - это называется "кодер". К сожалению, бывают и такие.

[ВасилийНиколаевич]

Знаю я одного программиста, который пишет набивалку ПФР для всей страны. Вот он как раз "чиста программист", не очень разбирается в той области, которую автоматизирует.
И в гоструктурах, к сожалению, это обычно правило, чем исключение.
В коммерческих структурах, как раз всё наоборот.

Ох уж эти коммерческие структуры, в которой программист "до всех школ" (юрист, бухгалтер, разработчик, программист, специалист по ремонту вычислительной и копировальной техники и т.д.)... Как пришлют отчетность не соответствующую формату данных (сформированную собственным ПО), так в ответ им отрицательный протокол, а при разъяснении (устном или письменном) рекомендация переформировать отчетность в "набивалке ПФР для всей страны" и это при условии что "набивалка ПФР для всей страны" сможет импортировать информацию из сформированной "отчетности" или "базы данных" коммерческой структуры.

[ВасилийНиколаевич]

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

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

Солидарен. Особенно это касается тех бухгалтеров, которые слабо себе представляют разработку программного обеспечения.

[yante]

Народ, давайте обсуждать программистов в других темах, а тут есть кому еще что по моему вопросу сказать???

[v_i_b]

А где найти в РСВ-1 сумму из Адв-6-2 СтрахУплач?

Для первого квартала Y2<= Адв-6-2 СтрахУплач <= Y1

Y1:=min ([250стр3столбец+ 100стр3столбец(положительная)] ,[ 140стр3столбец] )

Y2:=min ([250стр3столбец] ,[ 140стр3столбец - 252стр3столбец - 100стр3столбец(отрицательная) ] )

[Алексей К.]

Ирина, спасибо!

[Ирина55]

Может, сумбурно. Я изложила то, с чем конкретно столкнулась. Сейчас моя цель - понять программный продукт и дать стратегию работы в нем (как удобнее работать, план счетов, фиксированные проводки и т.п.). Пока самой очень сложно. Тем более все очень "заорганизовано".
Работала очень долго в большой организации с очень грамотным главбухом, которая весьма неплохо понимает проблемы постановки задач в подсистемах бухучета, в состоянии разработать такую аналитическую систему для своей организации, которая позволяла четко выбирать данные по бухгалтерскому, налоговому, статистическому и управленческому учету. Я практически была "с ее стороны" - т.е. выступала как заказчик практически по всем подсистемам бухгалтерского и кадрового учета. И выборку по любой строке декларации на прибыль подокументно для налоговой получали "в одно касание". Разработчики сторонние, но практически "свои" (т.е. работали четко под нас), ребята очень грамотные, а дотошными стать пришлось, т.к. мы четко знали, что хотели.
Когда привыкаешь очень многое решать настройками, очень сложно перейти на работу, когда программа практически "работает за тебя", а ты не знаешь, как ей сказать, что тебе так не надо. Звонишь в техподдержку, а там ответ простой - так работает программа. Хотите иначе - нанимайте программистов или заключайте договор с франчайзи. Это не наш вариант.

[VinnieThePOOH]

Звонишь в техподдержку, а там ответ простой - так работает программа. Хотите иначе - нанимайте программистов или заключайте договор с франчайзи. Это не наш вариант.

Типовой продукт.. Не учитывает особенности клиентов.

А вообще бухгалтеров поди пойми. Делаешь конфигурацию "под клиента" - высказывают претензию, что от нас попали в зависимость, и лучше работать на типовой программе, чтобы всегда можно было сменить фирму, которая обслуживает.

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

Единственный выход - работать уровнем выше, фактически исполняя обязанности главбуха, так, чтобы главбуха не волновали технические моменты - на каком ПО реализовано, что и как.

Главбуху все это неинтересно, главное - чтобы управляющие воздействия исполнялись, а на запросы был получен ответ в нужные сроки.