Как исправить модернизацию 1с

Получить 200 видеоуроков по 1С бесплатно:

  • Бесплатный видео самоучитель по 1С Бухгалтерии 8.2 и 8.3;
  • Самоучитель по новой версии 1С ЗУП 3.0;
  • Хороший курс по 1С Управление торговлей 11.

Liova08 08.03.2013
«Проведение документа: Модернизация ОС ТКД00000001 от 17.10.2012 12:00:00
По налоговому учету общая сумма модернизации, указанная в шапке документа, не соответствует в итоге суммам, отнесенным на основные средства!»
Перепроверила поступление жесткого диска, его передачу, услуги по установке. Всё проведено верно. В документе Модернизация сумма по налоговому учету автоматически заполняется по кнопке расчета – 3500. В видеокурсе она такая же, в рабочей тетради тоже. Сам момент проведения этого документа в видеокурсе отсутствует – сравнить не с чем. В видеокурсе мы сверяем данные только бухучета по 08.03. Я сформировала оборотку по счету по БУ и НУ. По НУ этой суммы нет, но в документ Модернизация она зашла автоматически. В видеокурсе (раздел 15 Проводки БУ) в журнале Модернизация ОС есть сумма БУ 3500, но графа «Сумма НУ» пуста (42-я секунда ролика). Я никогда не работала на УСН. Подскажите, пожалуйста, что я еще не проверила? Спасибо.

НИКОЛАЙ 08.03.2013
Добрый вечер с прошедшим Вас праздником!
В той же главе 15 Ольга четко говорит о том, что Документ Модернизация ОС никаких проводок по НУ не формирует

Liova08 09.03.2013
Добрый день! Николай, спасибо большое за поздравление.
Я уже покопалась и Интернете. В статье от 1С сказано, что услуги по модернизации необходимо приходовать документом Поступление товаров и услуг с операцией Объекты строительства, где на закладке Объекты строительства необходимо указать наш Сервер. Я не смогла провести такой операцией поступление Жесткого диска, но провести услуги по его установке удалось. При этом на закладке Объекты строительства я указала наш сервер и стоимость 1 руб. (без указания стоимости документ не проводится), а на закладке Услуги стоимость 1499 руб., т.к. в стоимость модернизации заходит вся сумма по документу, а она складывается из сумм по двум закладкам. Документ Модернизация перезаполнила в автоматическом режиме и, не поверите, документ провелся без всяких возражений. Я понимаю, что это из разряда «левой рукой, правой ногой», но я не поняла, в чем дело.

Svetlana73 09.03.2013
У меня такая же проблема!Ребята,если найдете ответ,напишите и мне тоже пожалуйста.Заранее спасибо!

Lada 10.03.2013
Попробуйте сделать как написано ниже: самое простое – заполните табличную часть «Основные средства» через кнопку «Заполнить» – «Для списка ОС». Тогда нужный реквизит «Сумма модерн. (УСН)» рассчитается и документ проведется.
Можно и в ручную заполнить, но это сложнее.

Lada 10.03.2013
Добрый день. :)
Проблема в том, что Вы заполняли табличную часть документа Модернизации ОС «Основные средства» вручную. Тогда нужно заполнять еще самим «Сумму модерн.(УСН)», которая в табличной части документа скрыта.
Открыть ее можно, щелкнув правой кнопкой мышки по заголовку таблицы в любом месте, и в выпавшем окошке выбрать последнюю строчку «Настройка списка», как показано на рисунке.
Отметить галочкой реквизит «Сумма модерн. (УСН)», нажать кнопку ОК или «Применить».
Проверьте, у Вас должно стоять в колонке сумма 3500.
Если Вы вводили строчку вручную, то она у Вас не заполнена.
Заполните и проводите. Все будет в порядке.
PS: Есть более простой способ уйти от этой ошибки.
Через меню «Заполнить» над табличной частью «Основные средства» выбрать «Для списка ОС» (программа предупредит, что пересчитает данные, Вы согласитесь).
В момент этого перерасчета программа автоматически рассчитывает и заполняет реквизит «Сумма модерн. (УСН)». Даже, если Вы не видите эту колонку, она заполнена.
Вы можете проверить это вышеуказанным способом, добавив к просмотру эту колонку.
При ручном вводе, не заполнив этот реквизит, Вы документ не проведете. Программа будет выдавать именно ту ошибку, о которой Вы писали: «По налоговому учету общая сумма модернизации, указанная в шапке документа, не соответствует в итоге суммам, отнесенным на основные средства!»

Lada 10.03.2013
После выставления реквизита «Сумма модерн. (УСН)» Документ проводится без проблем:

Дата публикации: Апр 19, 2013

Поставьте вашу оценку этой статье:

Загрузка…

Цитата
Гость написал:
БП 3.0. Не проводится документ модернизация ОС. Пишет ошибку, что основное средство не отражалось в учете в местонахождении. Как исправить ошибку? Как включить сумму модернизации в амортизационную премию?

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

________________________________________

До 5 бесплатных консультаций по 1С ежемесячно пользователям сервиса e-office24.ru

В соответствии с 5 пунктом ФСБУ 26/2020 «Капитальные вложения», утвержденный приказом Минфина России от 17.09.2020 №204н «Об утверждении Федеральный стандартов бухгалтерского учета ФСБУ 6/2020 «Основные средства» и ФСБУ 26/2020 «Капитальные вложения», модернизация основных средств – это способ улучшения основных фондов компании.

Фактические затраты на улучшение ОС в бухгалтерском учете признаются капитальными вложениями. Первоначальная стоимость объекта основных средств увеличивается на сумму завершенных капитальных вложений на улучшение объекта основных средств.

Разберем два примера модернизации основных средств в программе 1С:Бухгалтерия: с изменение срока полезного использования и без изменения срока полезного использования.

Без изменения срока полезного использования

ООО «ООО»  хочет модернизировать станок без изменения срока полезного использования. Срок полезного использования станка составляет 120 месяцев,  первоначальная стоимость объекта основных средств 567890 рублей. Организация применяет линейный метод начисления амортизации и в бухгалтерском и в налоговом учете.

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

Для модернизация основного средства организация купила элетродвигатель на сумму 7 000 тысяч. Поступление будет отражено документом «Поступление (акт, накладная)» с видом операции «Поступление товаров». В примере электродвигатель будет учтен на счете 10.06 «Прочие материалы», НДС будет учтен на счете 19.03 «НДС по приобретенным материально-производственным запасам». Проводим документ и выписываем счет-фактуру.

По кнопке    смотрим проводки, сформированные документом. Программа также сделелал движение по регистру «НДС предъявленный». Данный регистр предназначен для хранения информации о суммах НДС, предъявленных поставщиками приобретенных ценностей.

По ссылке в нижней части документа откроем счет-фактуру и проверяем ее заполнение. Если не стоит флажок «Отразить вычет  НДС в книге покупок датой получения», то  вычет отражается регламентным документом «Формирование записей книги покупок».

Если в качестве первичного документа и счет-фактуры получен УПД со статусом 1, то в документе поступления устанавливается переключатель УПД в положение включено.

При проведении документа поступления  автоматически будет автоматически будет создан документ Счет-фактура полученный. Посмотреть заполненную счет-фактуру можно по ссылке в поле «УПД». Переходим во все реквизиты.

Для передачи электродвигателя воспользуемся документом «Требование-накладная». Документ располагается в разделе «Производство».

Материалы списываются со счета 10.06 «Прочие материалы». Счет затрат выбирается в шапке документа по гиперссылке «Счет затрат». Выбираем счет 08.03 «Строительство объектов основных средств». Создаем объект строительства.

При списании электродвигателя программа сформирует в учете следующие проводки:

Для анализа учета сумм затрат на модернизацию станка есть возможность сформировать оборотно-сальдовую ведомость по счету 08.03 «Строительство объектов основных средств».

Для модернизации основных средств в программе предназначен документ «Модернизация ОС». Он располагается в разделе «ОС и НМА».

Выбираем объект строительства, на который списывается электродвигатель и счет затрат. Далее нажимаем на кнопку «Рассчитать сумму» и получаем стоимость электродвигателя.

Для того чтобы убедиться в том, что в стоимость объекта основных средств, в нашем примере станка, необходимо сформировать оборотно-сальдовую ведомость по счету 01 «основные средства». В нашем примере мы увидим увеличение стоимость станка на стоимость электродвигателя.

С увеличением срока полезного использования полностью самортизированного основного средства

Рассмотрим пример с увеличением срока полезного использования полностью самортизируемого основного средства. ООО «ООО» будет проводить модернизацию токарного станка с увеличением срока полезного использования. Первоначальная стоимость станка составляет  1 234 000, а срок полезного использования 36 месяцев. За счет установки новой системы ЧПУ срок полезного использования токарного станка увеличивается на 12 месяцев. У организации токарный станок был полностью самортизирован в феврале.

Модернизация будет проводится силами сторонней организации. Отразим услуги сторонней организации. Услуги сторонней организации отразим документом «Поступление услуг: Акт,УПД».  Автотрейд  2 февраля оказал услуги по модернизации токарного станка. Услуги были оказаны на сумму 50 000 рублей.

В табличной части документа выбираем счет учета 08.03 «Строительство объектов основных средств».

Документ сформирует в программе следующие проводки:

Также посмотрим счет-фактуру, которая была сформирована документом.

В счете-фактуре видно общую сумму, на которую были оказаны услуги. Отдельной строкой выделен НДС 10 000 рублей.

Создаем документ «Модернизация основных средств». В документе рассчитаем сумму, в примере 50000 рублей. Сумма рассчитывается исходя из стоимости услуг по модернизации.

Далее на закладке «Основные средства» указываем новый срок полезного использования с учетом модернизации.

Нажимаем на кнопку «Распределить». Далее проводим документ. В учете будут сформированы следующие проводки:

При формировании оборот-сальдовой ведомости за период проведения модернизации по счету 01 «основные средства» можно увидеть увеличение стоимости основного средства на сумму оказанных услуг по модернизации.

Остались вопросы? Специалисты компании «1С:БИЗНЕС РЕШЕНИЯ» помогут вам. Оставляйте заявку на сайте на бесплатную консультацию или звоните по телефону +7 (3532) 43-05-17.

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

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

Поломанные функции раздражают: однажды сделали доработку, проверили её со всех сторон, а после обновления она перестаёт работать. Почему так происходит, даже если обновлениями занимается хороший квалифицированный специалист?

Текст объемный, потому что мы рассматриваем проблему с разных сторон. Со статьёй можно погрузиться в тему и сделать управленческие выводы. В статье много терминов, но мы постарались всё перевести на понятный язык.

Три основных типа доработок в 1С

На вопрос «зачем вообще делать доработки в 1С» нужен большой развёрнутый ответ. Если коротко — доработки помогают улучшить систему и получить преимущество по сравнению с другими компаниями.

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

Сделать доработку так, чтобы она гарантированно не слетала после обновлений — невозможно.

    Доработки 1С могут быть такими:

  • Внешние доработки: печатные формы. отчеты и т.д.
  • Расширения
  • Изменения кода типовой конфигурации

Внешние доработки: внешние обработки, отчеты и т.д.

1С — сильная система, в которой многие процессы автоматизированы, но часто пользователи просят доработать программы чуть-чуть, по мелочи:

  • разработать специфические отчёты, которых не хватает
  • доработать или написать новые печатные формы с нужной информацией и оформлением

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

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

Как избежать ошибок?
Способ есть один и он универсальный для каждого варианта доработки системы. И он довольно простой — после обновлений нужно просто проверить каждую доработку. Как бы это ни звучало просто, возникает много нюансов и вопросов.


Когда возникают проблемы?

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

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

Что на самом деле делает программист при обновлении?
Обычно, программисты выбирают вариант ничего не проверять. Этот вариант и является оптимальным. Ошибки исправляются по обращениям пользователей (да, получается, что тестируют конечные пользователи). Но искать ошибку не надо, она уже найдена, обычно довольно понятна и может быть быстро исправлена.

Как снизить затраты на поддержку доработок?
Как раз для снижения затрат обычно и выбирается вариант — делать все без проверки. Если реально все проверять каждое обновление (и делать его раз в месяц), то затраты получатся большими, а проблемы встречаются нечасто.

Как повысить стабильность доработок?
Все внешние разработки поделить на критичные и некритичные. Критичные обычно влияют на оперативную работу компании. Например, если при ошибке в доработке остановится выписка документов, это повлияет на финансовые результаты компании.

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

Расширения: новое слово в доработках 1С

Расширения позволяют точечно дорабатывать 1С: делать заплатки в отдельных документах, добавлять нужные кнопки или писать целые подсистемы — новые функциональные блоки у программы. Доработки выполняются менее «инвазивным» способом и позволяют контролировать изменения основной конфигурации. Если изменение произойдет, разработчику будет выдано соответствующее предупреждение.

Многие пользователи, которые знакомы со значительными доработками 1С (особенно с горьким опытом предыдущих систем), знают понятие «конфигурация должна быть на замке». Это значит, что доработки выполняются внешними модулями, а ваша конфигурация останется нетронутой. С этой точки зрения расширения похожи на внешние доработки из прошлого пункта.

Расширения появились достаточно давно, но не все программисты их используют. Мы советуем присмотреться к этому механизму: он прост в использовании, не меняет основную конфигурацию 1С и помогает быстро добавлять нужные функции.

Почему могут не работать после обновлений?
Причина все та же (она будет всегда одинаковой) — код вашей конфигурации поменяли разработчики типовой конфигурации 1С, а доработки на него опирались, поэтому перестали работать.

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

Когда возникают проблемы?
В двух основных ситуациях:

  • доработки в расширениях сделаны неправильно (про это позже)

  • у вас установлено много расширений

Можно создать стандарты доработки расширений, мы работаем именно так. Стандарты помогают сократить частоту поломок после обновлений, но не избежать их на 100%.

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

Что на самом деле делает программист при обновлении?
Сама 1С обновляется легко, она же «на замке».
После обновления обязательно проверяется совместимость расширений с текущей версией программы.

Получается, не нужно проверять множество разных доработанных внешних программных модулей, а можно проверить всё в одном месте.

Спасает ли это на 100%? Нет, без «пользовательского тестирования» все равно не обойтись. Несмотря на то, что грамотно написанные расширения гораздо стабильнее, чем исправление внутри самой конфигурации, и много проблем позволяют выявить в автоматическом режиме.

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

Как повысить стабильность доработок?
В первую очередь нужно, чтобы разработчики создавали расширения по стандартам и грамотно их использовали.
Если простой для вашей компании критичен, а в программах 1С много расширений, можно обновлять не рабочую базу, а её копию. После обновления копии ваш пользователь или подрядчик тестируют критичный функционал. Если всё в порядке, обновляете рабочую базу с обновлёнными расширениями.

Изменения кода типовой конфигурации

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

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

Например, у вас есть документ Счёт на оплату. В него нужно добавить кнопку «Дать скидку до минимальной наценки». Для решения этой задачи не надо менять конфигурацию, достаточно написать внешнее расширение.

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

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

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

Если в каких-то местах ваш программист изменил код, то изменения от разработчиков 1С могут войти в конфликт с этими изменениями. В этом случае изменения вашего программиста стираются — код заменяется на типовой. Поэтому программисту, который обновляет доработанные конфигурации, нужно вручную отследить изменения и перенести их в новую конфигурацию. При этом важно не потерять изменение: человеческий фактор влияет максимально.
Хорошая практика — комментировать любое именение типового кода, описывать места изменений. Но и это спасает не всегда.

Как избежать ошибок?
Главное — не менять конфигурацию, если доработку можно сделать без этого. Если без изменений никак не обойтись, и это подтверждает грамотный программист, нужно доработать программу аккуратно, добавить пометки об изменении кода прямо в нём.

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

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

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

Что на самом деле делает программист при обновлении?

    Основная задача программиста при обновлении такой 1С — постараться не потерять изменения:

  • отметить места, которые слетели
  • вручную перенести затертый код
  • проверить, не выдает ли программа ошибку при запуске

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

Обычно на все эти процедуры уходит много сил и внимания разработчика, и о глобальной проверке «пользовательской работоспособности» уже никто не думает: она может занять намного больше времени, чем само обновление.

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

Если пришлось дорабатывать «по живому», то опять же самый простой и дешевый сценарий — это давать обновленную базу пользователям и в случае ошибок стараться оперативно исправлять. Однако частота возникновения ошибок уже довольно существенная.

Как повысить стабильность доработок?

    Тут много направлений:

  1. Работать над качеством разработки и комментирования кода.
  2. Если доработки ведутся несколькими программистами, налаживать коммуникацию и правила доработок.
  3. Вести документацию по обновлениям, фиксировать места, которые точно нужно проверить после обновления.
  4. Обязательно обновлять вначале копию, а потом уже рабочую базу.
  5. Составить чек-лист проверок критичного функционала и договориться, кто его будет проверять. В идеале нужно на копии базы подготовить примеры (тест-кейсы) по которым кто-то будет обязательно проходить и только после теста разрешать обновлять рабочую базу.
  6. Следить, чтобы тест-кейсы были не просто составлены, но и полностью проверялись. Если пользователи не проверяют обновлённую копию или просто делают там пару кликов, проверка не сработает.

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

Подытожим

  1. Дорабатывать 1С можно тремя основными способами: внешними доработками, расширениями и изменениями типовой конфигурации.
  2. Важно выбирать способ доработки исходя из целей, сложности поддержки и затрат.
  3. Нужно стараться использовать расширения, они не меняют типовую конфигурацию и создают меньше сложностей при обновлении.
  4. Разработчики проверяют работоспособность кода, синтаксические ошибки в нём. Но программисты не отратабатывают пользовательские сценарии.
  5. «Проверить, чтобы все работало», к сожалению, невозможно и нецелесообразно, но можно составить чек-лист критических проверок.
  6. Сама проверка функционала в «пользовательском режиме» — очень непростая задача, затратная, иногда, кажется, что бессмысленная: если проверяем уже 3-е обновление подряд, ничего не ломается, а времени тратится много.
  7. Нужно писать тест-кейсы, по которым реально проверить работу критического функционала.
  8. Важно следить, чтобы ответственные пользователи проверяли критический функционал: это снижает количество ошибок в дальнейшем.

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

А что делать, если хочешь дорабатывать 1С и испытывать меньше головной боли?

Автоматическое тестирование — инструмент, кторый помогает дорабатывать 1С. Автоматическое тестирование позволяет с одной стороны получать новые нужные функции, а с другой — не сталкиваться с постоянной поломкой критического функционала на рабочей базе.

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

Автотесты мы используем на собственных разработках и планируем внедрять автоматические тесты клиентам, чтобы повысить качество сопровождения программ 1С.

Добавить комментарий