Форум » » Вопросы и предложения разработчикам (часть 5) » Ответить
Вопросы и предложения разработчикам (часть 5)
Mon@x: Тема отслеживается разработчиками. Не все предложения будут приняты к реализации, но будут восприняты с благодарностью и рассмотрены. Часть 1 Часть 2 Часть 3 Часть 4
Б. Н.: pozmarin! Справка КБ-3 имеет две функции: - оплата работ текущего периода (месяца или части месяца); - накопление данных о стоимости стройки с начала года и с начала строительства. То, что Вам приходится отчетный месяц дробить на несколько частей, никак не влияет на то, выпускать или не выпускать соответствующие Справки КБ-3. Ответ - выпускать. То, что Ваш "месяц" длится, скажем, 10 дней, никак не отражается на текстах заголовка и шапки Справки КБ-3 (эти тексты официальные и изменению не подлежат). Так что, спокойно выпускайте для каждого Вашего отчетного периода (подпериода) соответствующую Справку КБ-3 и - успокойтесь. Никакого нарушения в этом не будет. Если от Вас зачем-то потребуют данные об объеме работ, выполненных за определенный месяц - выдайте соответствующую справку за подписью начальника и приложите к ней все Справки КБ-3 за этот месяц.
Valentin: 2.10.0Текстовый файл Пользовательской НСИ (НСИ_ПТ) предполагает полную свободу и демократию для пользователя при его создании. Вот и я так понял. Изменив пользовательскую Е12-22-1-А на стандартную Е12-22-1 мой текстовый файл АВК5_2100 принял успешно. В пользовательской НСИ АВК я нашел мою расценку Е12-22-1 (в ней я умышленно поменял текст на: "Стяжка 15", чтобы отличить от стандартной НСИ.). Теперь на уровне ЛС я явно задаю Е12-22-1... И что я вижу? Появилась вместо стандартной Е12-22-1 - моя пользовательская (Стяжка 15). Т.е. в этом механизме приоритет отдан НСИ_ПТ. При "тупом" наборе позиций очень даже можно наплодить множество незаконнорожденных . Это очень опасно. Предлагаю: при вводе ПТ из текстового файла не допускать ввод в АВК ( Пользовательской НСИ) шифров стандартных позиций.
Сергей.К: может имеет смысл сделать обязательные буквы(например УН или ПТ)
Valentin: Дело не в дополнительных буковках, а в том, что пользователь не сможет явно набрать ни одной позиции, если таковые имеются в пользовательской НСИ и имеют шифр стандартной. Такой глюк дает возможность написать вирус, который заражает всю стандартную НСИ и который не обнаружит ни один антивир, т.к. работаем с текстовым файлом. Ничего дополнять не нужно. В системе д.б. проверка уникальности шифра, тогда никаких совпадений со стандартными позициями не будет НИКОГДА!!
Сергей.К: так и я о том же...если будут обязательны дополнительные символы, то пользователь не сможет ввести норму состоящую только из стандартного шифра. или я не прав?
Valentin: Это уж как разработчики решат.
Valentin: V2.10.0 Пользовательские фрагменты, Группа строк из текстового файла, НСИ_ПТ не понимают Комплексных позиций. Очень хотелось бы, чтобы шифры КП были узнаваемы во всех механизмах внешнего взаимодействия.
Valentin: V2.10.0 Преобразование из одной ед. изм. в другую при увязке ТМЦ может быть довольно сложным. Здесь без определенных формул не обойтись. К примеру: ресурс АВК в 10м3, а ТМЦ в тн. Коеффициент отношения АВК:ТМЦ должен быть визуально расшифрован,чтобы пользователь мог всегда видеть алгоритмы своего расчета, т.к. это сделано в ЛС -"количество" . (в настоящей редакции задается Коефф. явным числом).
Valentin: Об увязке теории с практикой. Давно это было. Рекет в законе и сами законы довели меня, молодого директора, до состояния отрицательного финансового баланса. А продолжать работу нужно было, иначе -долги накроют.Штат необходимо было сократить почти до "0". Для сметного делопроизводства мне тогда уже нужен был ПК (для бюджета..., доселе все сметы и акты мы делали вручную). А оплатить ее было просто нечем. Я обратился к Игорю (ИНПРОЕКТ) чтобы помог "на шару" дать программу (АВК2). Я видел, как он закатывает глаза в потолок, в памяти расчитывает ответный номер компьютера, но договориться с ним так и не удалось. Спасибо за то, что бросил в "море".. Вспомнив о "...дело рук самих утопающих", я решил сам выкарабкиваться. Хоть и был на фирме главбух, но мне приходилось самому вести ряд красных, черных, белых и пр. бухгалтерий в программе 1С_V06. Базы всех нужных на тот момент строительных расценок в наличии не было, сборников было %10-15 не более. Я нашел дистрибутив АВК2 и начал над ним колдовать. При неправильной установке ПК все папки и файлы куда-то исчезали. Попробовал поискать то место, куда они удалялись. Нашел, восстановил, начал работать. В итоге я получил полноценный ПК лишь с тем ограничением, что не мог выпустить документы и + ограничение в некоторых расчетах. Это меня ничуть не смутило, и я задался целью соединить знакомую мне 1С с незнакомым АВК2. Соединил, сделал все в 1C (сейчас такой ПК есть в Росии на базе 1С Предприятие 7.7). Это был чудо-комплекс, в котором из таблиц ТМЦ я выбирал нужные ресурсы для ДЦ, вставлял их в ЛС и здесь же при формировании КБ2в все списывалось автоматически, без "красноты" и прочих нежелательных для бухгалтерии моментов. Выпускаемые документы были намного красочней АВК-шных и отражали в концовках все формулы расчета и промежуточные итоги. Но самое главное: была увязка материалов АВК с ТМЦ с выпуском соответствующего документа, который объяснял и бухгалтеру и проверяющему родословную каждой позиции любого ресурса. Еще я научил свой ПК думать комплексно и увязывать слова типа "ПАРКЕТНЫЙ ПОЛ" с набором соответствующих расценок и ТМЦ ресурсов. А вот когда были моменты проверок КРУ,тащить вагоны бумаг с объяснениями я себе позволить не мог. На мне где сядешь, там и слезешь. Появилась новая идея: СНИП-КОНТРОЛЬ. Эта опция в ПК позволяла мне привести мою документацию в законодательное русло. Т.е я мог всегда контролировать "правильность" моих смет и актов. Однажды я показал это проверяющим: этот момент был для них самым убедительным, т.к. на все их вопросы в одном документе были все ответы. Подводя черту хочу предложить разоработчикам АВК5 внедрить функцию: ДБН-КОНТРОЛЬ. Детали сокрыты, идея понятна. Но то, что ее внедрение перевернет всех с ног на голову: сомнений нет.
Valentin: Господа, разработчики, в документе OUTBOX.DOC на стр. 21 в самом тексте <данные о расчете цены> содержатся ошибки.
Valentin: В версии 2.10.0 радует то, что появилась возможность расчитывать ОПР по данным бухгалтерии, но не очень радует то, что данные в таблицы нужно вводить вручную. Все затраты имеют бухгалтерские счета, а это означает, что данные для расчета в ОПР за любой период (месяц, год) элементарно можно выгружать из любой бухгалтерской программы в текстовый файл. Задача разработчиков АВК автоматизировать заполнение таблиц из текстового файла. Пользователи будут ОЧЕНЬ благодарны. Щелчок - и расчет ОПР готов.
Valentin: В файле OUTBOX (V2.10.0) неправильно выводятся данные в строках ЛС: А5 – зарплата рабочих строителей и монтажников R1 – трудозатраты основных рабочих строителей и монтажников - данные попутаны местами (см.стр.10 описания файла)
exde: Valentin пишет: данные попутаны местами (см.стр.10 описания файла) Так шо? Шо попутано: данные или описание? Какая х/разница...Сажать надо, сажать! В маю!
Valentin: Во-первых: замечание адресовано разработчикам. Во-вторых: те кто уже пользуется файлом, начиная с 2.8.0, будут приятно удивлены, что в старых версиях все было ОК, а в новой - пропало количество, попутано вышеизложенное и т.д. Такое впечатление будто кто-то специально все рабочее испортил. В третьих: если уж exde так сильно заинтересовал этот вопрос, сравните выходные файлы ранних версий с новыми, и сами убедитесь. В четвертых: если нет разницы в смете между количеством, ТЗ и ЗП, то действительно, нужно САЖАТЬ!
exde: Valentin пишет: Во-первых: замечание адресовано разработчикам. Ну, звыняйте...
Valentin: В вопросе выпуска смет и актов все работает нормально.
exde: Valentin пишет: В вопросе выпуска смет и актов все работает нормально Спасибо за проверку. Если бы еще и вопрос с копейкой в КБ2/КБ3 окончательно решился.... А САЖАТЬ в мае надо ОГУРЦЫ И ПОМИДОРЫ!!!! а не разработчиков
Сергей.К: у меня в смете КБ2 итого: 2943650,05 грн НДС 588730,01 грн всего: 3532380,06 грн КБ3 итого: 2943650,05 НДС 588730,01 всего: 3532380,06 грн
Б. Н.: Valentin пишет: В версии 2.10.0 радует то, что появилась возможность рассчитывать ОПР по данным бухгалтерии, но не очень радует то, что данные в таблицы нужно вводить вручную. Все затраты имеют бухгалтерские счета, а это означает, что данные для расчета в ОПР за любой период (месяц, год) элементарно можно выгружать из любой бухгалтерской программы в текстовый файл. Задача разработчиков АВК автоматизировать заполнение таблиц из текстового файла. Пользователи будут ОЧЕНЬ благодарны. Щелчок - и расчет ОПР готов. Давайте разберемся. На мой взгляд, автоматизировать следует только полезную нужную работу. Введя в редакцию 2.10.0 таблицы для расчета ОПР и АР, мы просто вынуждены были подыграть нашим не шибко разумным чиновникам. Вы требуете от нас таблицы с правдоподобными строками затрат - получите их и отстаньте. Ни о каких объективных показателях, основанных на обработке реальных бухгалтерских данных строительной фирмы, здесь, по определению, нет и речи. Какой, вообще, смысл в этих таблицах? Если результат получится меньшим, чем усредненные данные, строитель спокойно глянет на потолок и дорисует затраты или же уменьшит (не учтет полностью) суммарную трудоемкость, собранную из Актов КБ-2в. Поди проверь! Если же результат получится большим, то проще просто срезать его, чем доказывать и обосновывать свое превышение над госстроевскими показателями. Больше ведь никак низзя! Так есть ли смысл автоматизировать до конца всю эту "методику"?
Valentin: Так и нормы ДБН также нет смысла автоматизировать? Ведь таблицы ОПР почти их зеркальное отражение.
Б. Н.: Valentin пишет: Так и нормы ДБН также нет смысла автоматизировать? Ведь таблицы ОПР почти их зеркальное отражение. Если быть точным, то в программе мы автоматизируем не нормы ДБН, а неоднократное обращение к этим нормам при составлении локальных смет. Здесь мы автоматизируем реальный полезный труд. А вот при расчете фактических показателей ОПР и АР речь идет об однократном действии пользователя по составлению таблицы, учитывающей зафиксированные в бухгалтерии затраты за прошедший год. Мы в программе четко расписали, как составляется таблица и что в нее входит - этого и достаточно. Составил таблицу единожды и ссылайся на нее при составлении всех локальных смет. Тем более, что само составление такой таблицы - занятие весьма сомнительное.
Valentin: Да все понятно, и тем не менее. Кто сталкивался с бухгалтерией на практике, тот знает, что получить сметчику данные для расчета ОПР - занятие бесполезное. Бухгалтера вечно заняты и подобные выборки делают с неохотой. Другое дело: нажал кнопку -сформировался файл и передал сметчику. А тот уже или подганяет под коеффициент или оставляет как есть -дело хозяйское. Нужен обычный механизм передачи данных. А за "нет" и суда нет.
Artem4ik: В версии АВК-5 2.10.0 существует нововведение: "В документах «Договорная Цена» и «Акт КБ-2в» расчет всех Прочих затрат производится и выдается на печать с точностью до 1 коп." Во всех предыдущих версиях АВК Прочие затраты в актах КБ-2в округлялись до 1 грн. Данное изменение очень усложняет процесс формирования справки КБ-3 и проверку её заказчиком, так как в справке, состоящей из более сотни актов очень сложно отследить ошибку в копейках. Убедительная просьба к разработчикам добавить функцию в программу, которая бы давала возможность выбирать пользователю приемлемый ему вариант: оставлять эти данные с копейками или же округлять их до целого числа. Заранее прошу не предлагать вариант вводить Прочие затраты вручную, так как речь идёт о большом количестве актов КБ-2в и округление в каждом из них займёт очень много времени.
exde: Artem4ik пишет: Данное изменение очень усложняет процесс формирования справки КБ-3 и проверку её заказчиком, так как в справке, состоящей из более сотни актов очень сложно отследить ошибку в копейках На калькуляторе составляют и проверяют, что-ли? Artem4ik Где нужно опасаться ошибки от большого количества цифр после запятой? Предупредите, пожалуйста, остальных пользователей 2.10.0
АВК: Замечательная функция - Выделение материалов в самостоятельную позицию. Плохо что при изменении объема работ не меняется объем материала. Нельзя ли эти цифры "запараллелить"?
Artem4ik: exde пишет: На калькуляторе составляют и проверяют, что-ли? Так как актов много и делают их несколько сметчиков, то выпустить общую справку КБ-3 для всех актов не представляется возможности, поэтому КБ-3 делается вручную по средствам EXCEL и данные вводятся именно вручную (как на упомянутом вами калькуляторе), а с копейками возростает вероятность ошибки и вследствии на поиск ошибочной копейки уходит уйма времени.
exde: Но ведь в КБ3 нет прочих затрат в явном виде? А КБ2/3 всегда были с копейками... Имеется в виду "из них строительно- монтажные работы"?
Artem4ik: exde пишет: Но ведь в КБ3 нет прочих затрат в явном виде? А КБ2/3 всегда были с копейками... Прочие затраты влияют на итоговые значения. В КБ2/3 выскакивали копейки максимум до 10 коп. от НДС и то не во всех актах. У нас с заказчиом даже были споры по поводу "материальных ресурсов поставки заказчика", которые выскакивали с копейками, сошлись на решении округлять их, вводя явно. А когда все прочие идут с копейками, то уж извините, вводить явно прибыль, административные расходы, комунальный налог, как то очень накладно. Во всех предыдущих версиях эти цифры всегда округлялись и с какой целью нужно было менять данную технологию расчета?
exde: Так вся проблема - в материалах заказчика? Как я себе представляю: 1. Сметчики самостоятельно могут в АВК откорректировать сумму материалов заказчика до копейки (могут, если захотят. Есть способ немножко схимичить). И тогда больше ничего трогать не надо будет 2. А к человеку, сбивающему общую КБ3, приходят уже нормальные КБ3 от сметчиков, с нормальными цифрами Вообще-то, для подгонки общей цены достаточно, например, коммунального налога. Вот тут-то и нужна точность до копейки. И других накруток тоже, чтобы он не выделялся
Valentin: АВК пишет: Замечательная функция - Выделение материалов в самостоятельную позицию. Плохо что при изменении объема работ не меняется объем материала. Нельзя ли эти цифры "запараллелить"? Ну и хитрун. Если позиция стала самостоятельной, так пусть себя и ведет самостоятельно. Веревочки зависимости уже обрезаны.
Сергей.К: АВК пишет: Плохо что при изменении объема работ не меняется объем материала. Нельзя ли эти цифры "запараллелить"? КП тебе в помощь
Valentin: Сергей.К , АВК хочет, чтобы объем расценки управлял объемом отторгнутых родственников с учетом норм расхода. Если применять КП, то только на каждую расценку, а это накладно.
АВК: Хитрун еще тот. "Отторгнутые родственники" были и раньше, только отторгали их вручную. Теперь эту процедуру автоматизировали. Смысла в этом особого не вижу. Единоразовая помощь, а дальше - всё по старинке. Я, правда, не пробовал, как эту функцию можно использовать в подрядчике, на демке пока юзаю. Согласитесь, то что я предлагаю было бы круто, не смотря на то, что хитро. Тем более, что при "очистке" нормы отторгнутые ресурсы восстанавливаются в составе нормы и при этом остаются самостоятельные в смете - их клоны. По запарке можно дров наломать. Если всё запараллелить, то при очистке ресурсов "отторгнутые родственники" должны вернуться в "семью". Из этого вытекает ещё одно: нельзя ли сделать действие функции очистки только на ту страницу, на которой нажата? К примеру, на странице "наименование" очищает только наименование, на странице "ресурсы" - только ресурсы.
Artem4ik: exde пишет: 1. Сметчики самостоятельно могут в АВК откорректировать сумму материалов заказчика до копейки (могут, если захотят. Есть способ немножко схимичить). И тогда больше ничего трогать не надо будет Вы меня не поймёте, с материалами заказчика проблем нет, они просто округляются в КБ-2, но неужели теперь нужно округлять Прибыль, Административные расходы, Комунальный налог (они теперь тоже выскакивают с копейками). exde пишет: 2. А к человеку, сбивающему общую КБ3, приходят уже нормальные КБ3 от сметчиков, с нормальными цифрами Человек сбивающий КБ3, делает справку не по "нормальным КБ3" а по актам КБ2, составляя при этом реестр актов, заказчик так же делает реестр актов, затем реестры сверяются и если где то не сходится цифра, начинают искать ошибку. С появившимися копейками эта процедура будет ещё сложнее. exde пишет: Вообще-то, для подгонки общей цены достаточно, например, коммунального налога. Вот тут-то и нужна точность до копейки. И других накруток тоже, чтобы он не выделялся Повторю ещё раз актов не 1 не 2 и не 3, чтоб заниматься подгонкой. Их количество уже почти доходит до 200 каждый месяц, а так как стройка в самом разгаре, то их будет ещё больше. То что вы предлагаете делать совсем не практично.
Valentin: Сверить 1000 КБ3 и не только по сотням объектов и с точностью до 1 коп. можно в доли секунд при помощи OUTBOX, тема аналитики уже обсуждается.
exde: Artem4ik пишет: с материалами заказчика проблем нет, они просто округляются в КБ-2 Да вот это и есть источник проблем! Задавайте реальную стоимость материалов в смете (а не явным заданием стоимости возврата или округлением) - и не нужно будет ничего больше трогать/округлять/подгонять и т.п. Или я не полностью представляю процесс составления реестра актов... Подгонки - это вообще от безысходности. Например - согласованная сумма после всех ухищрений с ценами не бьет на 1 копейку. Раньше в Екселе приходилось копейки править, в теперь можно задать в прочих затратах. Я очень доволен
Artem4ik: Valentin пишет: Сверить 1000 КБ3 и не только по сотням объектов и с точностью до 1 коп. можно в доли секунд при помощи OUTBOX, тема аналитики уже обсуждается. Пробовал работать с OUTBOX через СР2009, нашёл маленький недочёт. СР2009 берёт суммы из актов не те что выводятся на печать (с точностью до 1коп.), а расчётные (с точностью до 0,1коп.). В итоге если сбить все эти десятые копейки, а потом проверить сумму на калькуляторе с уже распечатанных актов кб-2, будут бить копейки. exde пишет: Задавайте реальную стоимость материалов в смете Я как то попробовал проделать данную операцию с субподрядчиком, в итоге столкнулся с проблемой: если сбить все показатели актов ("Итого (I+II+III+IV+V+VI+VII+VIII+IX)", "Стоимость материальных ресурсов поставки заказчика") и из них сформировать КБ-3, сделав все вычисления, накрутив НДС и т.д., то полученная сумма КБ-3 не всегда совпадает с суммой актов КБ-2 (сбитых просто на калькуляторе "Всего по объекту с учетом НДС"). Если же в актах округлены стоимости, как это было во всех версиях, то округлив лишь материал заказчика, мы не имеим подобных проблем. exde пишет: Раньше в Екселе приходилось копейки править, в теперь можно задать в прочих затратах. Не о каких исправлениях не может быть и речи, так как КБ-3 формируется после подписания КБ-2 всеми инстанциями и бегать переподписывать акт что бы исправить в нём копейки никто не будет.
Valentin: Artem4ik пишет: Пробовал работать с OUTBOX через СР2009, нашёл маленький недочёт. СР2009 берёт суммы из актов не те что выводятся на печать (с точностью до 1коп.), а расчётные (с точностью до 0,1коп.). ВСЕ посчитанные данные выбрасываются в ЕКСЕЛЬ. Задайте необходимую точность округления в формате ячеек .
Valentin:
exde: Artem4ik , регулярно работаю с материалами заказчика. В предыдущих версиях периодически были расхождения между Кб2 и КБ3 на 0,01 грн., не более. С этим боролись разработчики и, говорят, в 2.10.0 окончательно победили. Может, у нас разные подходы к формированию расчетов? Опишу свой, может, ошибаюсь где-нибудь 1. В "признаках" ставлю "суммарные стоимости материалов...... из ведомости ресурсов" 2. "Договорная цена - по рекомендациям налоговой" 3. Точность - до 1 коп. 4. Из Акта приема-передачи материалов вношу кол-во и цену (без НДС, ессно) в смету 5. Проверяю и вижу, что окончательная ИТОГО по Акту передачи и Ведомости ресурсов зачастую не сходятся, т.к. цена без НДС материалов может быть с несколькими знаками после запятой. 6. Корректирую ИТОГО материалов внесением в смету "фантомного" материала на +/- сумму 7. В выходных документах не забываю стереть добавленный ресурс. В итоге 1. Стоимость материалов заказчика совпадает в ведомости ресурсов и в Акте приемо-передачи 2. Все вычисления производятся автоматически, до любого знака, и не требуют подгонки 3. Все довольны: заказчик, подрядчик, бухгалтера И все - честно, на самом деле, т.к. правильно задать цену материала без НДС - не всегда возможно. "И никакого мошенничества"
полная версия страницы