Учет затрат на восстановление пришедших в негодность ОС
Восстановление осуществляется 3 способами: ремонт, модернизация и реконструкция.
Затраты на восстановление ОС отражаются в БУ того периода, к которому они относятся. Но затраты по всем видам ремонта не увеличивают первоначальную стоимость ОС, а списываются на себестоимость. А затраты на модернизацию и реконструкцию после окончания всех работ увеличивают первоначальную стоимость, поскольку при этом улучшаются потребительские свойства и показатели функционирования ОС. А отсюда и разное отражение в учете:
Дт 20,44 – ремонт Дт 08 – модернизация и реконструкция
После завершения работ 08 счет закрывается на 01.
Если ремонт выполняется собственными силами, то Дт 20,44 Кт 10, 70, 69.
Если ремонт делается подрядным способом, то Дт 20,44,19 Кт 60.
Выбытие ОС может иметь место в следующих случаях: продажа, списание, в случае морального износа, ликвидация при аварии и в чрезвычайных случаях, передача в виде вклада в УК другой организации, передача по договорам мены, дарения и т.п.
Принятие решения о списании осуществляется комиссией и оформляется в виде акта с указанием причин и обоснований этих списаний.
Если какие-либо детали и агрегаты могут использоваться как запчасти и материалы, то они подлежат приходованию по текущей рыночной стоимости Дт 10 Кт 91.
Акт на списание передается в бухгалтерию, в инвентарной карточке делается отметка о выбытии, затем 01 и 02 счета закрываются на 91 счет в следующей последовательности:
1. На 01 счете открывается субсчет «Выбытие ОС»
Дт 01 (выбытие) Кт 01 (эксплуатация).
2. Списывается начисленная ранее амортизация по выбывающему ОС
Дт 02 Кт 01 (выбытие)
3. Списывается остаточная стоимость выбывающего ОС
Дт 91 Кт 01 (выбытие)
4. Если в процессе выбытия организация получает какие-либо доходы (от продажи), то Дт 91 Кт 62 и НДС Дт 91 Кт 68.
5. Дт 91 Кт 99 или наоборот Дт 99 Кт 91 – прибыль/убыток от выбытия.
Придание иерархической структуре модульной программы хорошей формы позволяет улучшить процесс ее разработки. Число модулей, которые вызываются каким-либо модулем, и число модулей, которые его вызывают, оказывают влияние на сложность программы. Йодан (Yourdon) назвал число модулей, вызываемых из данного модуля, размахом или шириной управления модулями. Наряду с большим размером модуля, очень маленькая или очень большая ширина управления является признаком плохой схемы разбивки на модули. В общем случае, ширина управления модуля не должна превышать 10-ти. Это число связано с "магическим" числом 7, которое базируется на положениях психологии и, в особенности, на теории "кусков" ("chunking") информации. Кратковременная память человека имеет ограниченные способности сохранения "кусков" информации. Психологические эксперименты показали, что способность нашей кратковременной памяти находится в пределах 5-9 "кусков" (в среднем — 7). Она может одновременно оперировать около 7 "кусками" информации. Когда человек превышает этот предел, он более склонен к ошибкам. Реорганизация информации с разбивкой на подходящие части является важным действием для эффективного использования кратковременной памяти человека и для улучшения понимаемости материала. Люди во многих жизненных ситуациях делают такую реорганизацию бессознательно. Однако программист может сам себе помочь, сознательно допуская ширины управления модулями, которая превышает число 7.
Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями. А сам такой метод разработки программ называют модульным программированием. Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Программы разбиваются на модули для того, чтобы:
- упростить их разработку и реализацию;
- облегчить чтение программ;
- упростить их настройку и модификацию;
- облегчить работу с данными, имеющими сложную структуру;
- избежать чрезмерной детализации алгоритмов;
- обеспечить более выгодное размещение программ в памяти ЭВМ.
Не всякий программный модуль способствует упрощению программы. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих критерия:
- хороший модуль снаружи проще, чем внутри;
- хороший модуль проще использовать, чем построить.
Майерс предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики:
- размер модуля;
- прочность модуля;
- сцепление с другими модулями;
- рутинность модуля (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность(связность) модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Майерс не рекомендует использовать зависящие от предыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация является неконструктивной, так как во многих случаях именно зависящий от предыстории модуль является лучшей реализаций информационно прочного модуля. Поэтому более приемлема следующая (более осторожная) рекомендация:
- всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
- зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;
- в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных последующих обращениях к нему.
В связи с последней рекомендацией может быть полезным определение внешнего представления (ориентированного на информирование человека) состояний зависящего от предыстории модуля. В этом случае эффект выполнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления, что существенно упростит прогнозирование поведения данного модуля.
Напомним понятие и структуру модуля в терминах языка Pascal.
Модуль (unit) – программная единица, текст которой компилируется независимо (автономно).
Модуль содержит 4 раздела: заголовок, интерфейсная часть (раздел объявлений), раздел реализации и раздел инициализации.
