Коллеги!
Подскажите у нашей вышестоящей стоит программа "Финтех", а у нас 1С, можно как то выгрузить в эту программу, кто сталкивался?
Вид для печати
Коллеги!
Подскажите у нашей вышестоящей стоит программа "Финтех", а у нас 1С, можно как то выгрузить в эту программу, кто сталкивался?
выгрузить из Финтеха? Или отчет в Финтех?
Выгрузить можно, если узнать формат файла выгрузки, можно для 1с написать соответствующую обработку.
Выгружали из 1С и вручную набивали в Финтех. Программа желает оставлять лучшего
это уж точно, но ведь должно же что то измениться!!!
Сегодня сказали что так и будем делать отчеты в Финтех, потому что они победили конкурс на разработку программ для Минфина, что делать, может кото может написать выгрузку из 1с в финтех?
Мы за 1квартал тоже делаем в Финтех, что нибудь 1с рушили по этому поводу?
Найдите ближайшего фрайчайзи и закажите ему такую обработку.
Вот что говорят Финтех:
Мы планируем загрузку данных из Excel-я. Правда, сделаем это не раньше чем
через месяц, полтора.
Они конечно выиграли один из лотов, но это лот не по сбору отчетности об исполнениию бюджетов.Цитата:
Сообщение от НинаГеоргиевна
Свод и анализ отчетности в Минфине будет происходить на программном обеспечении другой фирмы.
Поздновато, конечно, но вот проходили мимо и заметили Вашу дискуссию...
Насчёт импорта данных из 1С: Финтех вёл рзработку такого модуля, но сейчас эти работы заморожены, т.к. ни один из субъектов не согласился предоставить массив данных, выгруженных из 1С (желательно реальных), для доводки (отладки) алгоритмов преобразования этих данных в отчёт. Написать всё вслепую, конечно, можно, но учитывая что бухгалтерского опыта у нас нет, пришлось бы решать эту задачу методом последовательных приближений, что не есть хорошо.
Ругайте конкретнее, что не так, почему не так?Цитата:
Сообщение от Моша
Разработчики, так все-таки будет загрузка из Excel? И вообще насколько возможно формировать отчетность в 1С, сохранять в Excel, а потом загружать корректно в Финтех?
Не припомню чтобы мы кому-то обещали импорт из Excel. Когда-то у нас был такой, но в силу произвольности формирования xls файлов мы отказались от него.
Однако. В 1С (в т.ч. и в конфигурации для бюджетных учреждений) есть выгрузка в текст (остатков, проводок и т.д.). Мы научили нашего тонкого клиента (если видели такого) читать эти файлы. Дальше надо просто преобразовать этот массив данных в отчётные формы. Дело оставалось за малым. Т.к. опыта ведения бюджетной бухгалтерии у нас маловато нужны были тестовые данные одного из субъектов и его же отчёт, дабы мы могли отладить алгоритмы. Но во-первых ни один субъект нам не согласился предоставить такого рода даные, а во-вторых МинФин затеял революцию в отчётности и было слегка не до этого.
Финтех, честно говорю, вашего ПО не видел, но!
ваше заявление
самый красноречивый ответ наЦитата:
но учитывая что бухгалтерского опыта у нас нет
Цитата:
Ругайте конкретнее, что не так, почему не так?
Разговор о проблемах загрузки утвержденных форм отчетности между разными программами, честно говоря, удивляет. Форматы утверждены Федеральным казначейством.
Финтех
Вспоминаю позицию Финтеха в прошлом году. Выгрузка в утвержденном формате реализована. А вот приема в этом же формате не было. И реализовывался он очень долго.
1C.
Со слов пользователей и тех файлов, которые нам присылали ощущение складывается, что о форматах компания 1С мягко говоря не в курсе.
Все реализуют свои форматы обмена.
Наверное, это маркетинговая политика такая. Покупайте только наши программы и мучайтесь ребята.
PJ7,
Это потому, что не видели нашего ПО. Оно не для бухгалтерского учёта. С 1С мы конкурировать врядли сможем, поэтому занимаемся сугубо отчётностью, с упором на свод, контроль по МинФиновским алгоритмами и выгрузкой в утверждённый формат... Необходимость в 21 веке вручную переносить данные из бухгалтерской системы в некую другую для создания отчётов коробит меня не меньше Вашего. Очень хотелось бы доделать то, что начали...
john_fed,
Тут проблема не в перебросе отчёта из одной программы в другую. Проблема в том, что либо бухгалтерская программа должна выгружать для МинФина полностью проверенные и отформатированные согласно требованиям файлы, либо программа предназначенная для сбора отчётности должна формировать этот самый отчёт на основании данных из бухгалтерской базы (т.е. проводки, остатки, и т.д.)
Не знаю что там в 1С с выходными файлами для МинФина (Казначейства), но для нас это всегда было приоритетно (и прописано в Договоре отдельной строкой).
А вот насчёт маркетинговой политики тут Вы не правы. Да не услышит меня моё начальство, но лично я считаю что специального пакета для отчётности быть вообще не должно. Бюджетная деятельность в идеале должна состоять из двух этапов: 1. Составление бюджета (планирование) и 2. Исполнение бюджета (тут всё просто, бухгалтерских программ навалом). Сейчас ещё есть и 3. Отчётность об исполнении. Но всем ведь ясно что 3 это всего лишь выходные данные от 2
Почему МинФин не организует такую простую схему - это уже вопрос к МинФину.
Окончательно я понял откуда растут ноги у этого бардака только на последней конференции (Ваши бухгалтера на неё ездили в МинФин не так давно). Там было сказано: МинФин собирает "Аналитический отчёт". Т.е. вся нагрузка по анализу данных об исполнении бюджета ложиться на Вас (на субъекты). Вы должны проанализировать Ваши данные согласно инструкциям, и в МинФин выслать результы Вашего анализа в виде всем знакомых форм. Согласитесь что гораздо проще собрать с субъектов простой массив бухгалтерских данных (в самом тривиальном случае - остатки на начало периода + проводки за период) и уже в МинФине проводить все виды анализа, которые их там интересуют.
Получилось много, но я пытался немного объяснить что мы, зачем мы и почему мы.
Вот это уже ответ.
Проблема в наличии утвержденного списка контрольных соотношений естественно лежит на Минфине.
Написать процедуру контроля с формированием протокола задача не сложная.
Тем более, что она уже давно есть.
У меня другой вопрос. Зачем нужны тысячи контрольных соотношений на различные промежуточные итоги, например в 428 форме. На семинаре в Минфине в декабре 2005г. был задан этот вопрос. На что было сказано, что да они не нужны, просто раньше Минфин их требовал. И все наши многочисленные пользователи Скиф ругается, если их нет. Это действительно так?
И все наши многочисленные пользователи говорят, что Скиф ругается, если их нет. Это действительно так?
Тут ситуация двоякая. Да МинФин объявил, наконец, что в текстовом файле ему промежуточные итоги не нужны. Наши кураторы на радостях новые формы наделали без них. После этого посыпались звонки от бухгалтеров, что МинФин МинФином, а они на экране хотят их видеть. Нам ничего не оставалось как вернуть их в боковики, натравить на них досчёт, но пометить как "невыгружаемые в текстовый файл". Но тут не обошлось без сложностей. В деталях уже не помню, но примерно смысл таков. Некоторые из этих промежуточных итогов должы были считаться везде, кроме 11 раздела. Скиф такого не умеет, при досчёте он считает, допустим по ЭКР: 210=211+212+213 для всех документов одинаково. А вот контроль, зависимый от документов, мы провести можем. Вот и получалось, что несколько строк мы вынуждены были с досчёта снять, но контролировать продолжали. Но таких строк ничтожно мало, несколько штук на такую большую форму, как 428, например...
Небольшая поправка. То что написано выше касается 123, 127, 128 форм. Т.е. тех форм, которые в качестве боковика имеют порядка 30 строк ЭКРов, а аттрибуты документов содержат в шапке формы. 428 же форма в качестве боковика имеет всю роспись. Алгоритмы досчёта там у каждой строки вбиты с учётом раздела (если не 11 то одни - иначе другие). В этой форме, если оператор провёл досчёт этих строк - в протоколе ругательств на эту тему быть не должно...
Большинство наших пользователей утверждает, что не им эти итоги нужны, а программе Скиф. В наше революционное время, когда идет перепрыгивание с одной инструкции на другую, когда бюджетная классификация постоянно меняется, это сколько всем труда нужно прикладывать по изменению бланков, по установке обновлений программы. Большинство к этому очень негативно относится.
В свое время, когда мы начали разрабатывать программу для федерального казначейства, вникали в их инструкции, я был удивлен отсутствием такого насаждения итогов в отчетности, наличием контрольных соотношений утвержденных инструкцией.
И вроде все, теперь сказали не надо. Нет же, тянем одеяло назад в прошлое.
Все тот же вопрос.
Если финансовый орган сформирует отчет без промежуточных итогов, выгрузит в утвержденный текстовый формат и попытается принять его в Скиф, будет ли ругаться программа на отсутствие этих итогов?
Или при приеме у вас сразу запускается функция досчета?
Я лично категорически против сбора промежуточных итогов (в смысле сохранения их в базе). Отображать на экране всегда пожалуйста. Но хранить, и, тем более, передавать в файлах...? ПО для сбора отчётности на самом деле всё равно. Можем хранить можем не хранить, но как только начинаем заниматься аналитикой - полный разброд. Одна задача собирает самые мелкие статьи и не досчитывает, другая то же самое но с досчётом, третья - вообще собирает только укрупнённые статьи. И сопрячь их в единой аналитичке весьма проблематично...
Но тут нужна единая политика, а её диктуем не мы.
А теперь ответ: все алгоритмы досчёта являются также и контрольными соотношениями. Т.е. если Вы после импорта недосчитанной, но имеющей досчёт формы Вы её не досчитаете - получите ошибки в протоколе.
Насчёт того что итоги на самом деле нужны Скифу - тут я Вас не совсем понял. Мы получаем на руки МинФиновский бланк и оцифровываем его. Если там есть итоги - они будут и в нашей форме, если нет, то их и не будет.
И вдобавок: как человек сидящий на поддержке могу утверждать: уберёшь итоги - звонят те, кто без них вообще не в состоянии набить отчёт. Вставишь - звонят другие, кому он мешает...
Уважаемый Финтех, мне таки не понятно - можно будет как то перекинуть данные из формы которую я выгрузил в Excel из бухгалтерской программы в файл xml, если можете напишите мне на e-mail, мне очень это необходимо.
ttu@74.ru
Стыковаться с 1С мы будем не через Excel, а через текст (В 1С ведь есть экспорт в текст). Компонента, которую мы разрабатываем будет прикручиваться к тонкому клиенту, и на выходе дествительно будет получаться отчёт в XML файле.
Получается, что сейчас удовлетворена одна половина, которой нужны итоги, а вторая так и продолжает жаловаться. Странное решение проблемы.Цитата:
Сообщение от Финтех
Я всегда считал, что в первую очередь программа должна отвечать инструкции, а уж потом, путем настроек, позволять пользователям рулить процессом.
Досчёт у нас дело добровольное - не нужен - не нажимайте кнопку. Таким образом довольны могут быть все желающие...
Уважаемый Финтех!
Поясните ещё раз, будет (или есть) в вашей программе импорт данных в формате федерального казначейства (текст)?
В Скифе3 был есть и будет, в тонком клиенте не будет...
Но если не досчитаете, то получите на нескослько страниц протокол не существующих на самом деле ошибок. И разбирайся потом, где действительно ошибка, а где так итог. Выход один однозначно добровольно принудительно делать досчет.Цитата:
Сообщение от Финтех
что нибудь слышно по Финтех? сделали они загрузку в свою программу откуда нибудь?
Ничего они не сделали, наш программист написал выгрузку ф.128 из 1С:БМО в Скиф3, сейчас пытается написать програмульку выгрузки балансов, фин.результата, пояснительной из 1С Свод отчетов в Скиф3. Если кто пробывал напишите
Прочитал переписку.Не знаю, плакать или смеяться?
Как! Как могла компания, работники которой ничего не знают о бухучете (сами признались) выиграть конкурс на написание программы отчетности для МинФина?
Да здравствует XML! EXCEL -отстой!
Вот только размер файлика в этом формате, мягко говоря, зашкаливает за здравый смысл, особенно в свете передачи его куда-то по каналам связи. Не верите, сравните выгрузку НДФЛ в текстовом и XML-форматах.
в 2004 сдавали на дискетках, в 2006 - на дисках. Некоторые - на DVD.
Или я ошибаюсь?
Добрый день!Цитата:
Сообщение от Финорган
Если у Вас есть выгрузка из 1С:БМО в Скиф3, то нельзя ли ее приобрести?
Просто столкнулись проблемой большого числа выгрузок (по числу клиентов) в Скиф...
1C реализовала выгрузку в текстовый формат по МинФиновским требованиям из конфигурации Бухучёт бюджетных учреждений. Вопрос должен был отпасть сам собой. В связи с этим мы свою компоненту изъяли из пакета (вернее не саму компоненту, а формы, предназначенные для импорта из 1С).
Это закон ИТ рынка. Нанимаемая компания вполне может вообще ничего не знать о предметной области. Если мы возмёмся писать ПО для учёта, напрмер, перелётных птиц - это не значит что мы орнитологи. Бухгалтер ставит задачу - программист пишет программу. С течением времени программист начинает поверхностно разбираться в бухучёте, но Вы ведь не ждёте что его можно поставить главбухом? Именно это я имел в виду в упомянутом Вами признании.Цитата:
Сообщение от YUM
Кстати это всё живёт и жить будет отчасти ещё и потому, что отчёт об исполнении бюджета имеет отношение к бухучёту лишь немногим более тесное чем к балету, например. Это нигде не афишируется (вслух это звучало только на семинаре в Москве в 2005 году) но МинФин (или Казначейство - всё равно) собирают АНАЛИТИЧЕСКИЙ отчёт. Т.е. некто в МинФине (как раз специалист по бухучёту) сочиняет некоторые алгоритмы анализа исполнения бюджета. В результате этого анализа должны получиться некие аналитические формы отчётности. А формы эти - это простые таблички ячейки которых связаны друг с другом некими контрольными соотношениями. Таким образом связь с бухучётом очень сильно ослабевает, что и даёт возможность влезать в драку компаниям не специализирующимся на бухучёте. (Это уже не только о нас, но и о других фирмах, периодически выигрывающих тендеры в МинФине).
Вы правы. Самый прекрасный формат - текстовый. XML - это разновидность текстового формата с мощной разметкой. Но за мощность мета языка приходиться платить размером. Но никто ведь не мешает сжать XML перед отправкой?Цитата:
Сообщение от YUM
На Всероссийском совещании в Волгограде Вашему представителю был задан вопрос о приеме в текстовом формате в программе FREPORT. Ответ был примерно следующим:Цитата:
Сообщение от Финтех
В этой программе вы его реализовывать не планируете(причины трудоемкость, частые изменения форматов) и посоветовал переходить на СКИФ3. Значит ли это, что рабочее место удаленного пользователя FREPORT уже не поддерживается?
Экспорт в текст у нас сугубо серверная компонента. Реализовать тот же функционал на FReport действительно довольно трудоёмко, т.к. реализовать импорт надо из любого текстового файла ибо они довольно часто меняются и по разным задачам разные.
Поддержку мы осуществляем на прежнем уровне и будем осуществлять и впредь. А вот развивать эти версии FReport и Скиф мы прекращаем (за исключением уж совсем необходимых функций для реализации новых отчётов) т.к. идёт работа над следующим поколением этих программных комплексв.
Смысл ответа, данного мной на конференции, был в том, что если Вам жизненно необходим импорт из текста Вам следуем установить однопользовательскую версию Скифа - по деньгам получится тоже самое.
ФинТех 34: "Это закон ИТ рынка. Нанимаемая компания вполне может вообще ничего не знать о предметной области." Конечно, если её цель - наварить бабла и свалить, ей даже лучше ничего не знать о предметной области, чтобы не отвлекаться на ненужную рефлексию.
Это просто нападка ради нападки?
Мы этим занимаемся 25 лет и пока никуда не свалили...
Нет, Вы определитесь, пожалуйста: либо занимаетесь "этим" 25 лет, либо "компания, работники которой ничего не знают о бухучете".
Где правда-то?
Если первое правда - то наезд (37) признаю необоснованным.
А где противоречие?
"Это" - это отчётность об исполнении бюджета, и я по-прежнему утверждаю что эта отчётность так же далека от бухгалтерии как я от балета.
Кроме того основной наш пакет это "Бюджет РФ" в МинФине. А уж он точно НИКАКОГО отношения к бухучёту не имеет.
И предлагаю прекратить оффтоп... Потому как спор больше философский, чем предметный. А значит результат будет нулевой с большой долей вероятности. :)
