Конфигурация для бюджетых организаций

[Djam]

Благодарю. Буду смотреть.

[Djam]

А что касательно плана счетов? Тут куда копать? Или лучше сразу на уровне справочников его делать?

[app]

Да. Специального бизнес-объекта под план счетов в Ананасе не предусмотрено. С задачей хранения свойств счетов должен справиться справочник.

[nsa]

жалко, что только сейчас нашел этот форум
есть какие-либо промежуточные результаты?
на чем остановились? или только поболтали и все?

я достаточно хорошо знаком с бюджетным учетом. больше 10-ти лет занимаюсь внедрением Паруса. есть в моем активе проект для бюджета на Парус 8 (в качестве СУБД используется Oracle). немного знаю 1С. так что знаю положительные и отрицательные стороны двух этих основных для исполнения сметы программных продукта. Да, есть еще Криста со своей АС-Смета, есть Барс, на котором работают в нескольких регионах. Но все эти программные продукты имеют недостатки. И мне бы хотелось поучаствовать в создании софта, лишенного этих недостатков.

Идея создать программный продукт для бюджета под лицензией GPL достаточно интересная. Тем более, что Ананас система кросс-платформенная. А 1С и Парус декларируют работу своих программных продуктов под Линуксом (Парус объявил о новой платформе Торнадо, которая для разработки использует продукты MS, а разработанные решения работают и под Линуксом с использованием Моно). Они понимают, что делаются шаги со стороны государства в сторону открытого софта. Один из примеров- Тверская область. Или проект в Минобре РФ. С апреля месяца 2010 года школы переходят на Линукс. А Барс, хоть и только под виндой работает, софт раздает бюджетным учреждениям бесплатно, но через 2 месяца начинает собирать деньги с тех.поддержки.

Последний пост сюда был в августе, так что если все еще есть желающие участвовать в этом, то давайте проведем для начала "перекличку", определимся с рабочей группой, нарисуем план действий и т.п.

[app]

Готов участвовать, но хотелось бы видеть перспективы внедрения в конкретном учреждении/организации. Чтобы по результатам работы родилась история внедрения с плюсами и минусами. Чтобы ТЗ первого этапа удалось минимизировать и контролировать сроки в ходе работ.

[nsa]

что имеется в виду под ТЗ первого этапа?
это то, что написано в первом посте?
так я считаю, что для бюджетного учреждения это сейчас не важно, т.к. у них есть уже программные продукты, осуществляющие взаимодействие с казначейскими системами. в программу бюджетного учета необходимо передать из казначейской системы уже готовый документ. по умолчанию 1С и Парус (я буду сравнивать с этими программными продуктами) предполагают, что необходимо подготовить документ в бухгалтерской системе, а потом путем экспорта/импорта передать его в казначейскую. в итоге получается, что во многих казначейских системах (я не говорю про СЭД) после списания денег с лицевого счета присваивается свой номер. но номер это мелочи. чем мотивируют разработчики такой порядок экспорта/импорта? а тем, что в бухгалтерской системе есть проводки и к проводкам привязана классификация расходов, а в казначейской системе проводок по определению нет. Но в некоторых проектах пошли по обратной схеме, платежка готовится в казначейской системе а потом экспортируется и импортируется в бухгалтерскую (в Нижнем Новгороде таким образом реализовали экспорт платежек из АЦК-Финансы компании БФТ). А одни умельцы сделали вообще классно, в Парусе написали на фокспро функцию, которая лезет в БД казначейской системы (в данном случае это Криста, УРМ) и формирует проводки.

Потом мне не понравилась фраза

Конфигурация для бюджетных организаций.
...
3) По возможности бухгалтерский учёт. Для бюджета он значительно проще, чем для коммерческой организации, .

это не так, он не проще. он просто другой. и нужно начинать с бюджетного учета.

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

но с бюджетом сложнее, они тратят не свои деньги. хотя, если будет решение и стоимость владения которым будет достаточно низка, то ИМХО можно отхватить часть рынка. или нужно вылазить на федеральный уровень. на федеральном уровне сейчас решения с открытым кодом вроде как пользуются поддержкой. последние примеры- создание типовой медицинской информационной системы (МИЦ), проект по переводу школ на Линукс (АйТи и ее дочка, см http://www.it.ru/new_1509.html).

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

[Glaf]

Давайте определимся с терминами.
"Казначейская система" - это программный продукт, используемый в органах Федерального казначейства. В настоящий момент это "Центр-КС", изначально разработанный Чебоксарским Кейсистемс, а сейчас с переменным успехом дорабатываемый Компанией ОТР.
С 2010 года планируется заменить это ПО на "АС ФК", разрабатываемый группой компаний с участием той же ОТР.
"Транспортная система" - программный продукт, предназанченный для гарантированной доставки электронных документов от организации-клиента в орган ФК и обратно. В настоящее время это СЭД, официально являющийся подсистемой ПО "Центр-КС". СЭД был разработан на основе "Вин-транспорта" компании БФТ (БСС).
Для "АС ФК" разрабатывается собственная транспортная система "СУФД", котрая будет работать через веб-интерфейс.
Сроки внедрения СУФД размыты. На первом этапе АС ФК будет взаимодействовать с клиентами через СЭД. Для этого в ПО разработаны специальные "шлюзы" - конвертеры форматов.

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

Речь идёт о СЭД? СЭД предназначен для передачи документов. По сути, это "продвинутая электронная почта".
В СЭД не предназначен для ведения учёта документов, а также для более-менее автоматизированный их обработки, например, уточнения невыясненных.

в программу бюджетного учета необходимо передать из казначейской системы уже готовый документ. по умолчанию 1С и Парус (я буду сравнивать с этими программными продуктами) предполагают, что необходимо подготовить документ в бухгалтерской системе, а потом путем экспорта/импорта передать его в казначейскую.

То есть, организация должна создать документ у себя, в своей учётной системе, а затем при помощи транспортной системы (СЭД) передать этот документ в казначейство.
Именно так. СЭД - единственный официально разрешённый программный продукт, с помощью которого можно передать документ в электронном виде. Поместить документ в СЭД можно только при помощи структурированного файла, формат которого утверждён ФК.

в итоге получается, что во многих казначейских системах (я не говорю про СЭД) после списания денег с лицевого счета присваивается свой номер.

СЭД - не казначейская система. Номер документа всегда присваивает создатель, то есть учётная система, используемая организацией-клиентом. Будь то 1С, Парус, ПРО-Бюджет и т.д. Затем этот документ со своим номером отправляется в казначейство при помощи СЭД. Номер документа ни в СЭД ни в Центр-КС не меняется.
Может, вас смущает порядок проведения кассовых расходов?
Поясню. Согласно Приказу 8н, с 01.01.2009 бюджетная организация предоставляет в орган ФК на платёжку, а Заявку на кассовый расход. Платёжные поручения формируются и направляются в банк органом Федерального казначейства. Орган ФК должен информировать клиента о платёжных документах, сформированных на основании его Заявки.
В бухгалтерском учёте факт кассового расхода отражается на основании Заявки на кассовый расход, подтверждённой выпиской из лицевого счёта клиента, отрытого в органе ФК. Платёжки с 01.01.2009г в бюджетном и бухгалтерском учёте бюджетной организации не фигурируют никаким образом. Это только "справочный документ", например, для общения с контрагентом.

чем мотивируют разработчики такой порядок экспорта/импорта?

Приказ 8н о кассовом обслуживании. Разработчики в порядке экспорта-импорта ничего не придумали.

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

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

Но в некоторых проектах пошли по обратной схеме, платежка готовится в казначейской системе а потом экспортируется и импортируется в бухгалтерскую (в Нижнем Новгороде таким образом реализовали экспорт платежек из АЦК-Финансы компании БФТ).

По-видимому, вы имеете ввиду, что Заявки готовятся клиентом ФК в СЭД, а платёжки, сформированные ФК, загружаются в АЦКу?
Странно, надо будет уточнить у разработчиков и нижегородских сопровожденцев, почему они пришли к такому решению, не вполне соответствующему актуальной нормативной базе.

А одни умельцы сделали вообще классно, в Парусе написали на фокспро функцию, которая лезет в БД казначейской системы (в данном случае это Криста, УРМ) и формирует проводки.

Ох уж эта Криста! Знаем

Потом мне не понравилась фраза

Конфигурация для бюджетных организаций.
...
3) По возможности бухгалтерский учёт. Для бюджета он значительно проще, чем для коммерческой организации, .

это не так, он не проще. он просто другой.

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

и нужно начинать с бюджетного учета.

Возможно. Конкретизируйте ваши предложения.

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

но с бюджетом сложнее, они тратят не свои деньги. хотя, если будет решение и стоимость владения которым будет достаточно низка, то ИМХО можно отхватить часть рынка. или нужно вылазить на федеральный уровень.

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

на федеральном уровне сейчас решения с открытым кодом вроде как пользуются поддержкой. последние примеры- создание типовой медицинской информационной системы (МИЦ), проект по переводу школ на Линукс (АйТи и ее дочка, см http://www.it.ru/new_1509.html).

Ознакомьтесь с изначальным вариантом госзаказа по переводу школ на Линукс, под который были выделены средства. И сравните его с результатом. Рекомендую также внимательно ознакомиться с протоколами конкурсной комиссии по НП-12.
Sapienti sat

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

Любая активность, приводящая в движение проект, только приветствуется

[nsa]

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

что касается приказа 8н, то он регламентирует формы документов и форматы обмена данными с УФК.
и если порядок будет обратный (данные будут попадать на пример из УРМа или СЭДа в бухгалтерскую программу), то ничего страшного в этом не вижу. это никакое не нарушение.

в связи с тем, что бухам приходится вводить дважды информацию (я говорю про УРМ), и они в бухгалтерской программе сразу регистрирут выписки с ЛС, то я пришел к выводу, что раздел "Банковские документы" нужен не в первую очередь. именно в том виде, в котором он есть в большинстве бухгалтерских программ.

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

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

[Glaf]

но кроме УФК есть еще и региональные финансовые органы, которые создали на своей базе казначейские отделы.

На взаимодействие бюджетополучателей и финорганов бюджетов регионального и местного уровня Приказ 8н не распространяется в случаях, если лицевые счета клиентов открыты на балансе лицевого счёта финоргана. Тут уж кто во что горазд! У нас в городе, например, каждой бюджетной организации открывают кучу лицевых счетов с буквенно-цифровым наименованием длиной, как бы не ошибиться, 30 с лишним символов(!!). Для каждой БК свой счёт. И ведь клиенты как-то умудряются сводить эти лицевые счета в один
Так что у вас ещё не худший вариант
Вообще-то, ещё с 2004 года планировалось принять положение, по которому дотационные регионы не имеют права содержать собственное казначейство. Все счета бюджетополучателей должны быть открыты в органах ФК, дабы обеспечить прозрачность и госконтроль за тем, куда уходят деньги "бедных" регионов. Что считаю хорошо и правильно. Но региональное лобби, очевидно, весьма сильно. К 2010 году это положение так и не введено.
Предлагаю не подстраиваться под требования каждого конкретного региона. Они продиктованы в первую очередь ограничениями ранее закупленного софта. А унификация документооборота различных бюджетов - вопрос времени.
Кстати, в программе развития бюджетного федерализма в Российской Федерации на период до 2005 года, утвержденной Постановлением Правительства Российской Федерации 15.08.2001 года за № 584, говорится: "К 2005 году должен быть в основном завершен переход региональных и местных бюджетов на казначейское исполнение на основе единых федеральных стандартов. Кассовое обслуживание бюджетов субъектов Российской Федерации и муниципальных образований, не перешедших на казначейское исполнение в соответствии с федеральными стандартами, а также бюджетов высокодотационных регионов, регионов, находящихся в финансовом кризисе или в режиме внешнего финансового управления, будет осуществляться территориальными органами федерального казначейства".