Бухгалтерский учет. Налоги. Аудит

Форум – МСФО, US GAAP

Обсуждаем:

Re: Внутренне созданный НМА

3e4r5t (99c3d)
19.01.2018, 17:19
тут будет большая проблема не в учетном плане, а в организационном.

Чтоб Вам своевременно "умельцы" говорили что они что-то мастерят. Потому что Вы можете и не узнать, что они что-то сделали.
avatar
Escapist  
19.01.2018, 21:16
Используется плановая трудоемкость. Любая доработка после ввода в эксплуатацию должна делаться по заданию (запросу на изменение), проходить стандартные шаги - бизнес-требования (методология), проектное решение, разработка, тестирование, перенос в продуктив, актуализация технической документации.
В режиме текущего времени устраняются инциденты(ошибки) - это поддержка, которая конечно не капитализируется.
taxcons  
22.01.2018, 10:19
3e4r5t
Escapist
Последующие доработки в виде процента изменения функциональности будет сложно измерить. Трудоемкость доработки - более удобный критерий.
Трудоемкость конечно удобный критерий, но не всегда сразу видна трудоемкость, а затраты уже списал в текущий период и их не вернуть
То есть нужен критерий, который изначально позволит понять что будет создан НМА и начать собирать затраты. Лучше по внутреннему документообороту смотреть
Например, если дается отдельное задание, формируется группа по созданию доработки, то в НМА, если в режиме текущего времени все решается, то просто расход. 
Технический проект практически на любой шаг заводится, включая самые несущественные, поэтому как критерий наверное не подойдёт. . Понимаю  что изменение функциональности это будет сугубо экспертное суждение ИТ, которое, во первых они не факт пока что согласятся давать, а во вторых не будет таким прозрачным для тех же аудиторов например
Про плановые часы на каждый проект попробую узнать, а также оценку ИТ , какое количество часов труда разработчиков по опыту ИТ приводит к существенному изменению программы
3e4r5t (99c3d)
22.01.2018, 16:03
taxcons
Технический проект практически на любой шаг заводится, включая самые несущественные, поэтому как критерий наверное не подойдёт. . Понимаю  что изменение функциональности это будет сугубо экспертное суждение ИТ, которое, во первых они не факт пока что согласятся давать, а во вторых не будет таким прозрачным для тех же аудиторов например
В бюрократии (формализации процедур) есть свои плюсы.
Инициируете изменение формы Технического задания, куда добавите обязательное поле "вид работы", где, к примеру, 3 варианта из списка: исправление ошибок; незначительная доработка; значительная доработка - изменение функционала/дополнительная обработка.
И еще одно обязательное поле - обоснование существенности.
И согласия ИТ никто и спрашивать не будет, это станет их обязанностью.
Можно добавить ограничение: ХХХ ч*дней как критерий существенной доработки.
Точное значение ХХХ определите из стоимости трудодня работника ИТ и уровня существенности по учету.
taxcons  
23.01.2018, 10:07
Если по факту выясняется, что большая часть работ это доработка,/модернизация уже эксплуатируемых ПО , стоит здесь тратить время выделяется капитлизируемые затраты или считать всё текущей поддержкой сопровождением программ? По пояснения ИТ грань может быть очень тонкой
taxcons  
23.01.2018, 10:08
Разработки тоже есть но меньше,, их буду отдельно рассматривать
Исправлений: 1; последнее - в 23.01.2018, 10:56.
avatar
Escapist  
23.01.2018, 19:06

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



По пояснения ИТ грань может быть очень тонкой
Выбирайте критерии, которые имеют объективную оценку, а не профсуждение отдельного специалиста. Не забывайте, что вы не перекладываете принципы МСФО на ИТ-язык с комментариями - это никому не нужно. Должны быть сформулированы конкретные правила для вашей компании на основе общих принципов МСФО.
Автор:
Ваш Email:

Защита от спама:
Введите код, который вы видете ниже (защита от роботов-спамеров).
  ******   ********         **  **     **   *******  
 **    **  **     **        **  **     **  **     ** 
 **        **     **        **  **     **  **     ** 
 **        ********         **  **     **   ******** 
 **        **         **    **  **     **         ** 
 **    **  **         **    **  **     **  **     ** 
  ******   **          ******    *******    *******  
Сообщение: