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

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

taxcons  
19.12.2017, 09:30
Организация  имеет в штате программистов, которые, в том числе, занимаются разработкой нового, либо доработкой существующего (созданного не самой организацией) программного обеспечения. Исключительные права на данные разработки/доработки ПО не регистрируются. 
С точки зрения признания внутренне созданных НМа могут быть сложности с точки зрения наличия контроля над практиками ,(нет правовой охраны), я правильно понимаю?
3e4r5t (99c3d)
19.12.2017, 11:50
taxcons
С точки зрения признания внутренне созданных НМа могут быть сложности с точки зрения наличия контроля над практиками ,(нет правовой охраны), я правильно понимаю?
если заработная плата и другие расходы списывались на расходы периода, то признать НМА нельзя.
Если же собирались отдельно и в расходы периода не списывались, то можно.
3e4r5t (99c3d)
19.12.2017, 11:53
Правовая защита (свидетельство) роли не играет, так как критерием является "контроль"
avatar 19.12.2017, 23:53
3e4r5t
Правовая защита (свидетельство) роли не играет, так как критерием является "контроль"
Критериев там таки чуть больше. Сложности могут быть именно с контролем — если после первой продажи вероятно появление клонов на рынке и отсутствие/снижение следующих продаж, то «будущие экономические выгоды» сомнительны, как и весь актив. 
То же самое, если доработка производится под конкретного клиента: собрали затраты, списали на проект и забыли, потому что сомнительно в будущем найти ещё такого же клиента и получить новые экономические выгоды.
avatar
Escapist  
20.12.2017, 00:29
Доработка под конкретного клиента оплачивается, поэтому ее логично упаковать в затраты по проекту до его завершения НЗП. Ноу хау при этом останется у разработчика и в его интересах прописать в контракте право использовать его для других проектов. По-моему, данный кейс скорее про разработку и доработку покупного ПО для собственных нужд, так как при оказании услуг на сторону контрактной защите интеллектуальной собственности уделялось бы большее внимание.
При разработке для собственных нужд - тест на принципиальную возможность продажи/передачи права докажет идентифицируемость, фактическая эксплуатация ПО в производственной деятельности - критерий экономической выгоды, базовая защита интеллектуальной собственности (трудовые договоры программистов, политика конфиденциальности, ит-безопасность) - возможность ограничить доступ третьих лиц к выгодам.
Для ПО технически выполнить критерии НМА обычно не сложно - на этапе создания (внедрения) ПО. Но какие-то доработки обычно продолжаются весь период эксплуатации, и на практике их бывает сложно разделить на поддержку систем, которая относится на расходы, и расширение функциональности, которое можно капитализировать.
taxcons  
20.12.2017, 10:05
Spiridonov
3e4r5t
Правовая защита (свидетельство) роли не играет, так как критерием является "контроль"
Критериев там таки чуть больше. Сложности могут быть именно с контролем — если после первой продажи вероятно появление клонов на рынке и отсутствие/снижение следующих продаж, то «будущие экономические выгоды» сомнительны, как и весь актив. 
То же самое, если доработка производится под конкретного клиента: собрали затраты, списали на проект и забыли, потому что сомнительно в будущем найти ещё такого же клиента и получить новые экономические выгоды.
Да не было пояснения - разработка и доработка программ ведется исключительно для своих внутренних нужд, системы учета и тп, ничего не продается
avatar 20.12.2017, 11:08
taxcons
Да не было пояснения - разработка и доработка программ ведется исключительно для своих внутренних нужд, системы учета и тп, ничего не продается
А, ну в таком варианте обычно проще всё доказывается. Капитализируйте затраты, проверяйте 6 признаков НМА и спокойно амортизируйте на срок использования.
Если есть возможность разбить по каким-то модулям с отдельной функциональностью — разбивайте в учёте, потому что (по опыту) года через два-три будет ситуация, когда один модуль перепишут, а три других возьмут от старого проекта и будет у вас задачка списать затраты по неиспользуемым модулям.
taxcons  
20.12.2017, 21:53
Escapist
Доработка под конкретного клиента оплачивается, поэтому ее логично упаковать в затраты по проекту до его завершения НЗП. Ноу хау при этом останется у разработчика и в его интересах прописать в контракте право использовать его для других проектов. По-моему, данный кейс скорее про разработку и доработку покупного ПО для собственных нужд, так как при оказании услуг на сторону контрактной защите интеллектуальной собственности уделялось бы большее внимание.
При разработке для собственных нужд - тест на принципиальную возможность продажи/передачи права докажет идентифицируемость, фактическая эксплуатация ПО в производственной деятельности - критерий экономической выгоды, базовая защита интеллектуальной собственности (трудовые договоры программистов, политика конфиденциальности, ит-безопасность) - возможность ограничить доступ третьих лиц к выгодам.
Для ПО технически выполнить критерии НМА обычно не сложно - на этапе создания (внедрения) ПО. Но какие-то доработки обычно продолжаются весь период эксплуатации, и на практике их бывает сложно разделить на поддержку систем, которая относится на расходы, и расширение функциональности, которое можно капитализировать.
Escapist спасибо! за, как всегда, подробный развернутый комментарий.  Возможность продажи дальнейшей не рассматривается, по крайней мере на данный момент никто не рассматривает. Разработки достаточно уникальны, и почти всегда в основе разработки лежит либо уже созданное ПО, либо платформа для разработки (надо кстати посмотреть в последнем случае как предусмотрены в договоре с лицензиатом ограничения на дальнейшее использование созданного на их платформе
В общем случае продажа не планируется, да и скорее всего она не будет возможна по причинам, описанным выше - нет регистрации и правовой защиты, разработки чаще на базе чужих программ или платформ. 
В совокупности все это говорит не в пользу признания НМА наверное. В то же время таких довольно много, их результата организация будет использовать не один год.. Сумы существенные. Нередко идет доработка приобретенного ПГ штатными программистами совместно с разработчикаом создателем продукта ( он на свои услуги по настройке и доработке выставляет акты ежемесячно,)
  Наверное все таки сложно говорить здесь про внутренне созданный НМА
Исправлений: 1; последнее - в 21.12.2017, 09:48.
avatar
Escapist  
20.12.2017, 23:22
МСФО не предназначено для учёта контрафактного ПО)) Поэтому если лицензия производителя (вендора) запрещает заказчику доработки под себя, то вопрос капитализации доработок этого ПО - неурегулированная зона. Могут быть в лицензии ограничения на передачу разработок 3-м лицам. Начните изыскания с этого. Если доработки разрешены, то ещё раз повторю, на практике обычно не возникает трудностей с классификацией их как НМА _до ввода в эксплуатацию_. После ввода повышается вероятность, что эти доработки будут неотделимы от текущей поддержки. Организация как правило разрабатывает критерии для разграничения одного от другого. Критерий стоит сделать двойной - как стоимость отдельной доработки, ниже которой капитализация в принципе не рассматривается, так и существенность доработки с точки зрения функциональности. Если ПО используется как корпоративное (шаблонное для нескольких компаний Группы), расширение организационного объёма (тираж) обычно также рассматривается как капитализация. Также нужно определить единицу учёта НМА - действительно как рекомендует коллега Spiridonov это часто отдельный функциональный модуль. Если проводить докапитализации тиражей и существенных изменений функциональности - то единица учёта может быть и мельче, чем модуль. Чем относительно больше компания инвестирует в ИТ, тем более релевантен для неё будет большая детализация учёта НМА по сравнению с допущением отнести все на текущие расходы.
taxcons  
22.12.2017, 09:53
Escapist, большое сп­асибо, постепенно про­ясняется план действи­й дальнейших.
То есть. изначально п­о всем договорам лице­нзионным определяем, ­есть ли ограничения н­а право продавать рез­ультаты доработок ПО.­ Скорее всего есть. Т­огда с признанием НМА­ вопрос снимается, т.­к. несоответствие кри­терию идентифицируемо­сти, верно?
Если таких ограничен­ий нет, тогда разраба­тываем дальше учетную­ политику по капитали­зации таких  доработо­к/разработок ПО

Исправлений: 1; последнее - в 22.12.2017, 09:58.
3e4r5t (acb80)
24.12.2017, 16:36
taxcons
То есть. изначально п­о всем договорам лице­нзионным определяем, ­есть ли ограничения н­а право продавать рез­ультаты доработок ПО.­ Скорее всего есть. Т­огда с признанием НМА­ вопрос снимается, т.­к. несоответствие кри­терию идентифицируемо­сти, верно?
а еще не мешает заглянуть в трудовые договора программистов.
Исходя из контекста ,ну как видно юридической основой особо не занимаются, может оказаться что все права принадлежат программистам (по праву авторства), а не конторе.
3e4r5t (acb80)
24.12.2017, 16:42
taxcons
То есть. изначально п­о всем договорам лице­нзионным определяем, ­есть ли ограничения н­а право продавать рез­ультаты доработок ПО.­ Скорее всего есть. Т­огда с признанием НМА­ вопрос снимается, т.­к. несоответствие кри­терию идентифицируемо­сти, верно?
нет, не верно. Критерий - это не возможность продажи третьим лицам (отчуждаемость), а контроль  и получение выгода от обладания.
Контроль это положение о коммерческой тайне и отнесение этих доработок к коммерческой тайне организации (приказом) - это первое что сделать нужно, СВК, мероприятия по запрету на копирования персоналом, трудовые договора, в который прописано что все принадлежит конторе и работник (автор) не имеет право брать себе и прочее, прочее
Выгода - снижение трудоемкости учетной работы или иной автоматизируемой работы и т.п.
taxcons  
25.12.2017, 10:08
Т.е. по вашему равное чтобы не было запрета дорабатывать ПО , возможность продажи не обязательна

Как тогда с критерием идентифицируемости?

12 Актив удовлетворяет критерию идентифицируемости, если он:
(a) является отделимым, т.е. может быть обособлен или отделен от организации и продан, передан, лицензирован, предоставлен в аренду или обменен индивидуально или вместе с относящимся к нему договором, идентифицируемым активом или обязательством, независимо от того, намеревается ли организация так поступить; или
3e4r5t (99c3d)
25.12.2017, 10:40
taxcons
возможность продажи не обязательна
taxcons
обособлен или отделен
Возможность (юридическая) продажи необязательно об этом, если мне не изменяет память, прямо прописано. Но есть возможность передать и основное ПО и доработки (т.е. "вместе с относящимся к нему договором").
К тому же там стоит "или" т.е. или обособлен или продаваем.
Но проблема с контролем (организационная) есть во всех конторах, что я видел. 
Кроме того, как показала моя практика, многие продавцы САП и технологического ПО не имеют право его продавать, так как у них нет соответствующих лицензий от Оракла. Особенно это относиться к производственному (технологическому) ПО (управление производственными линиями) и сопряжение этого ПО с САП.
Так что, все это на уровне субъективного восприятия - можно или нельзя.
Т.о. если не заморачиваться правами на интеллектуальную собственность очень сильно (а если углубиться то легко можно прийти к выводу что все контрафактное - отсутствие сублицензии на Оракл, к примеру), то доработки ПО (создание отчетов, загрузка/выгрузка складских остатков и прочее), модули сопряжения САП и технологического ПО, удовлетворяют критериям и могут быть поставлены на учет.
Проблема возникает со СПИ таких доработок. Я по модулям сопряжения технологического ПО и САП ставил СПИ равным сроку СПИ технологической линии.
taxcons  
26.12.2017, 22:08
То есть в принципе будет достаточно, если в лицензионных договорах не будет запрета на доработку исходного ПО для своих целей, плюс для подтверждения контроля внутренние положения, , условия в трудовых договорах с программистами что все их разработки собственность компании, и обязательства по конфиденциальности...  Пополнений учет трудозрпт программистов - и можно попробовать классифицировать как НМА.
Исправлений: 1; последнее - в 27.12.2017, 10:13.
3e4r5t (99c3d)
27.12.2017, 11:06
taxcons
доработку исходного ПО для своих целей
Если, упрощенно, Вы написали макрос для Экселя, то можно сказать что это доработка исходного ПО для своих целей. Но по факту это создание своего ПО, работающего на базе Эксель.
Доработка исходного ПО это когда вносятся исправления в код, общем случае если нет исходников: делистинг (дизассемблирование) - правка кода - компиляция в библиотеку или исполняемый файл. Это всегда запрещено и всеми.
У Вас скорее всего написана приблуда для печати отчетов или автоматизации загрузки/выгрузки данных или конфигурация для 1С. Это не правка исходного ПО.
Вы сначала определитесь что именно смастерили умельцы из Айти отдела - идентификация объекта.
taxcons
можно попробовать классифицировать как НМА.
не забывая при  этом делать это теперь всегда. 
А так же помня, что восстанавливать уже списанные и отраженные в расходах предыдущего периода затраты для формирования первоначальной стоимости (стоимости признания) запрещено.
taxcons  
29.12.2017, 09:51
Учту ваши пояснения, насколько я знаю есть как  создание дополнотелых отчетов,  так и ведется доработка приобретенного ПО (совместно с разработчиком!) . В общем все вопросы будем обсуждать на встрече, ближайшей, надеюсь все проверим, в том числе выясняю какой характер носят доработки
taxcons  
18.01.2018, 17:23
3e4r5t
taxcons
доработку исходного ПО для своих целей
Если, упрощенно, Вы написали макрос для Экселя, то можно сказать что это доработка исходного ПО для своих целей. Но по факту это создание своего ПО, работающего на базе Эксель.
Доработка исходного ПО это когда вносятся исправления в код, общем случае если нет исходников: делистинг 
А как вы считаете,  можно ли считать существенной доработкой ПО действия в рамках следующих условий 
Лицензионного соглашения: 
" Лицензиат не вправе без письменного специального разрешения Правообладателя вносить какие либо изменения в код программного продукта, с помощью технических средств и решений, не предусмотренных в сопроводительной документации " 
Это стнадартная формулировка из лицензионного соглашения с 1С
taxcons  
18.01.2018, 17:46
И  можно ли считать что действия в рамках описанного лицензионного соглашения могут привести к внутренне созданным НМА?
На мой взгляд нет
taxcons  
18.01.2018, 18:34
С другой стороны это пользовательские настройки в рамках конфигуратора могут быть настолько существенными и с их помощью в итоге создана настолько индивидуальая база под пользователя,  что-то почему нельзя их считать внутренне созданным НМА? 

Другой вопрос что , как обсуждалось выше, необходимо тогда установить грань где заканчивается доработка существенная программного продукта и далее начинает вестись его настройка..
Поскольку работы по донастройке и велись и ведутся, а программа уже давно активно используется, надо уже и расходы/амортизацию признавать
После начала использования например уже считать что все дальнейшие доработки являются текущей настройкой, и только в случае если яяИТ дает данные что ведутся. существенные работы по модификации ПО, то рассматривал вопрос об их капитализации, возможно, отдельной то ранее признанного НМА
Исправлений: 2; последнее - в 18.01.2018, 19:33.
avatar
Escapist  
18.01.2018, 22:20
"Лицензиат не вправе без письменного специального разрешения Правообладателя вносить какие либо изменения в код программного продукта, с помощью технических средств и решений, не предусмотренных в сопроводительной документации"
Это стандартное защитное условие, которое признанию доработки существенной не мешает. Существенность определяется новой функциональностью, а не типом использованных для ее реализации техническими средствами и решениями.
avatar 19.01.2018, 01:19
taxcons
И  можно ли считать что действия в рамках описанного лицензионного соглашения могут привести к внутренне созданным НМА?
На мой взгляд нет
Да, почему бы и нет. Вы же конфигурацию создаёте - уникальный продукт, ваш, никаких прав у 1С на вашу конфигурацию нет. И опять же, даже если бы вы что-то там с нарушением правил создали — это ваш внутренний НМА, вам и капитализировать.
«Про внесение изменений в код» — это про саму программу, а не про конфигурации, имхо. 
taxcons  
19.01.2018, 11:43
Спасибо,Escapist. Появляется уже много сомнений и вопросов именно в связи с разделением что считать настройкой,  и что считать доработкой, надо сначала определиться с этими суждениями. В нормативных документах, в том числе в ГК определения доработки конечно нет - поправьте если я ошибаюсь,, ну в общем случаем все права пользователя лицензии прописываются в лицензионном договоре..Но я согласшаюсь с вашими рассуждениями - почему нельзяи считать существенной доработкой существенные настройки программы через конфигуратор, с использованем открытого кода, в рамках пользовательской лицензии

В общем следующий шаг будет определять сущесьвенность для разграничения доработки; то настройки ПО,  Как вариант бюджет на персонал свыше такой то суммы и изменение функциональности программы на 50% по сравнению с исходным функционалом... Примеррно в таком духе..
avatar
Escapist  
19.01.2018, 13:58

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

Нет смысла делать различие на настройку конфигурации и доработку - в обоих случаях используются документированные возможности ПО или интерфейсы к нему в рамках прав, предоставленных вендором.
Первоначальная настройка/доработка от исходной версии "из коробки" перед вводом НМА в эксплуатацию должна быть капитализирована полностью. Последующие доработки в виде процента изменения функциональности будет сложно измерить. Трудоемкость доработки - более удобный критерий.
3e4r5t (99c3d)
19.01.2018, 17:11
Escapist
Последующие доработки в виде процента изменения функциональности будет сложно измерить. Трудоемкость доработки - более удобный критерий.
Трудоемкость конечно удобный критерий, но не всегда сразу видна трудоемкость, а затраты уже списал в текущий период и их не вернуть
То есть нужен критерий, который изначально позволит понять что будет создан НМА и начать собирать затраты. Лучше по внутреннему документообороту смотреть
Например, если дается отдельное задание, формируется группа по созданию доработки, то в НМА, если в режиме текущего времени все решается, то просто расход. 
Автор:
Ваш Email:

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