Изменение ФКР

[Gross]

Районные отделы внутренних дел... Да и не только они...

В 2005 г. имела место ФКР, к примеру, 188 03 02 247 00 00 ххх, в рамках которой сложились остатки финансовых, нефинансовых активов и обязательств.

В 2006 г. смета доведена уже по ФКР 188 03 02 202 00 00 ххх
В соответствии с методологией 70н это уже новый "комплект" счетов в плане счетов.

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

Как с этим разобраться?

1. Обеспечение целостности финансовых потоков в разрезе ФКР - это выдумка идеалистов в учете и вполне допустимо Дт 188 03 02 247 .... - Кт 188 03 02 202..... ?

2. В учете в 2006 году мы "говорим 188 03 02 202, подразумеваем 188 03 02 247". При ручном ведении учета в регистрах зачеркиваем 247, а над ним надписываем 202. При программном - переименовываем номера счетов для тех систем и вариантов настроек, в которых первые 17 знаков являются непосредственно номером счета, либо переименовываем объекты аналитики, если первые 17 организованы по такому принципу?

3. Оставляем 247 как было, заводим еще "комплект" счетов для 202. ОС, ТМЦ, обязательства, капвложения и т.д. проводками переводим в 2006 г. со 188 03 02 247 ..... на 188 03 02 202.... ?

4. ..........................

5. ..........................


Интересует профессиональное и общественное мнение по этому поводу...

[BorisG]

Интересный вопрос.
И не первый раз тут уже задан.
См., например, пост #23 и #24 Не тот КБК
И ответ на него, на самом деле несложен, он заложен в самом принципе бюджетной классификации, и его очень явно можно увидеть, этот ответ, если например, внимательно посмотреть приложение 10 к новому Закону "О федеральном бюджете на 2006 год".
Т.е. неверны варианты ни 1, ни 2, ни 3

Другой вопрос, что этот принцип свертки КБК, хорошо известный тем экономистам, кто "верстает" бюджет, прошел стороной как разработчиков инструкции, так и разработчиков ПО.

[Gross]

заложен в самом принципе бюджетной классификации, и его очень явно можно увидеть

Под этим принципом подразумевается каталожная структура кодов функциональной классификации?

Т.е., в основе - финансовый поток по Администратору в целом, который потом детализируется на Разделы, Подразделы, Целевые статьи и т.д. ...





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

Что касательно изначально обозначенного вопроса...

У самого недоумения - как задумана эта система увязки Бюджетной классификации и ФКР как элемента счета?

Борис подкрепил их "крамольными" соображениями о том, что у экономистов одно видение этой системы, а у разработчиков инструкции и ПО - несколько иное.

Для кого картина ясна, проблем нет, и есть конкретные решения по данному вопросу - поделитесь ...

[BorisG]

Gross, на самом деле с КБК все действительно стройно.
И действительно, попробуй поговорить с теми, кто формирует бюжет, кстати, неважно, какого уровня. Для них нет проблемы "свертки" по КБК.
Каждый поле (или группа полей), которое левее, имеет бОльший приоритет. Кстати, это не мои слова, их явно озвучил высокопоставленный чиновник Минфина.

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

[BorisG]

Ну и немного крамолы
Читаем приложение 10 Закона "О федеральном бюджете на 2006 год"

Органы внутренних дел 188 03 02
...
Воинские формирования (органы, подразделения) 188 03 02 2020000
...
Реализация гос. функций, ... 188 03 02 2470000

Т.е. при изменении КЦСР (и любого другого кода, уровня ниже), или его добавлении, объект должен быть "поднят" на уровень выше, т.е. в данном случае на 188 03 02 0000000.
Однако расходные КБК по нему в текущем отчетном периоде должны быть строго те, что заложены в смете.

[Gross]

нет проблемы "свертки" по КБК.
Каждый поле (или группа полей), которое левее, имеет бОльший приоритет.

Да... Это ясно...

пока ни в одном документе по учету, и ни в программных продуктах, пока нет свертки по полям бюджетной классификации. А жаль. На самом деле это было очевидно с самого начала.

А есть какие-нибудь идеи, как наиболее разумно поступить сейчас в части изначально обозначенного вопроса?

[BorisG]

А есть какие-нибудь идеи,

Да, собственно, не идея.
Если программный продукт позволяет относить затраты на вышестоящий КБК, сделать как написал выше.
Если нет, просто пока переименовать КБК, и все.
Причем, заметь, это не хозяйственная операция.
Т.е. не должно быть проводок.

ps: Что-то подсказывает мне, что до отчетности в разрезе КБК не дойдут руки у разработчиков и в этом году.

[Gross]

У КБК каталожная структура... Чем "левее" код, тем выше у него приоритет... Ведем речь о возможности свертки КБК влево...

С этих позиций следует понимать, что проводки Дт 188 03 02 247 .... - Кт 188 03 02 202..... допустимы ?

[BorisG]

С этих позиций следует понимать, что проводки ... допустимы ?

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

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

ps: Но... это пока только теория. Что сейчас придумает в этом свете Минфин... не берусь даже загадывать. Тем более, как я понял, он взял паузу.

[Дмитрий В.]

Прошу простить за наивный вопрос:
В чем смысл изменения уже существующих кодов?
Понятно, когда добавляются новые коды или детализируются уже существующие, но зачем нужно один код заменять на другой?
Это один из самых фундаментальных вопросов, которые меня беспокоят.
Психологически это воспринимается как терроризм в отношении к бухгалтерам (Они это именно так и воспринимают). Но я понимаю, что среди разработчиков террористы не числятся. Скорее руководствовались благими намерениями. Может это просто "по русски": хотели как лучше, а получилось как всегда.
Интуиция мне подсказывает, что все эти объяснения надуманы. Просто я не понимаю какого-то фундаментального закона.
Боюсь (в хорошем смысле), что я наконец смогу получить здесь ответ.