Вот в этом ключевой момент: во-первых, шифрование факта просмотра. Мне не кажется, что мир в котором настолько всё шифруется — это нормально. ВЫ хотите — вы используете VPN/TOR/что вам угодно. А сейчас мы говорим, что все разработчики должны исходить из того, что дать возможность оператору узнать о факте доступа к публично доступной информации — это плохо.
То есть глубина паранойи определяется не потребителем, не источником, а интернетом как таковым. При этом тенденция в том, что даже источник не должен определять необходимо ли что либо шифровать или нет. Ну… мне не нравится, когда кто бы то ни было диктует что бы то ни было. Даже если это благожелательное сообщество беспокоится о моей безопасности.
Для проверки целостности не обязательно требуются подписи, можно обойтись хэшами, если они пришли из подписанного/зашифрованного документа.
В данном случае первая претензия моя в первую очередь эстетическая: инструмент (шифрование) используется ненадлежащим образом. При этом происходит определённое навязывание шифрования как вещи столь фундаментальной, как будто ничего вообще без него работать не может (включая запрос аптайма с роутера).
С практической точки зрения… ну я не имел бы ничего против, если бы мой провайдер кешировал у себя популярные ролики с ютуба, чтобы сэкономить на трафике и дать мне более высокую скорость. При этом ему бы не потребовалось получать у Гугла защищённое оборудование, могущее шифровать каждый ролик от имени Гугла. Подпись при этом может браться у Гугла, а вот данные уже локально.
Вообще-то это означает, что мы используем шифрование не по назначению. Шифрование должно использоваться, чтобы защитить данные от перехвата. Для того, чтобы защитить данные от подмены надо использовать механизмы подписей и хэшей, отличающиеся тем, что данные могут быть доступны и вне шифровки.
Ну… правила передаются по защищённому каналу, а содержимое — по незащищённому.
А сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому(интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity). Я пытаюсь оппонировать именно позиции «передавать всё-всё-всё по защищённому, всё что не передаётся по защищённому — потенциально скомпрометировано», которую как раз и продвигает Хром.
Мне кажется вы не совсем корректно формулируете претензии: человек же по сути обсуждает не своего провайдера, а будущее интернета в котором каждый котик должен передаваться в зашифрованном виде.
Вопрос не в том, как ему быть с провайдером, а насколько (и почему) котики требуют шифрования.
Что случится если этот комментарий не будет зашифрован?
Что случится если график в посте не будет зашифрован?
Что случится если лого Яндекса не будет зашифровано?
Суть в том, что вместо того, чтобы шифровать всё мы шифруем только html, содержащий ссылки и хэши. А картинки и видео не шифруем. Таким образом сайт/поддомен отвечающий за раздачу медиаданных может работать без шифрования.
Современный подход требует шифровать вообще всё (сайт, загружающий нешифрованные картинки помечается как «не совсем безопасный»)
Да не то, чтобы другую. Если расширить механизм SRI на img/audio/video то можно было бы использовать механизмы в духе CDN или просто прозрачных проксей для публично доступных медиаданных.
Ну в общем-то если в организации по каким-то причинам бухгалтерский и налоговый учёт полностью разделены, то да, можно иметь именно такие две амортизации.
Но хотел я сказать не это. Хотел я сказать, что для того, чтобы понять что такое амортизация можно (и нужно) начинать с полезного срока эксплуатации и износа. А «регламентированная» амортизация выводится из этого внесением «регламентов»(НК и ОКОФ). Но амортизация начинается не с регламента и регламент не является её неотъемлемым свойством.
Со станком наоборот: считаем стоимость станка, оцениваем его срок полезного использования (используя ОКОФ, документация производителя, здравый смысл и опыт). Делим одно на другое — получаем амортизацию. Складываем амортизацию с другими расходами на изделие и смотрим окупается у нас изделие или нет.(например при 10 тыс. окупается, а при 5 тыс. — нет)
То же с туалетом. Срок эксплуатации… ну я не особо эксперт в этих делах, но я бы закладывал до первого капитального.
>Ну и зачем?
То есть бухучёт по-вашему вообще не нужен? Я вот не представляю, например, организации масштабов хотя бы НИИ, не говоря о чём-то большем, которая могла бы обойтись одной банковской выпиской для управленческих решений.
> учет должен вестись по всем фактам (действиям)
Вот здесь вы резко и принципиально смешали факт и действие. Факт: человек работает. Совершенно не каждый час отмечается в учёте и даже дни собираются в табели обычно пост-фактум, а не в виде ежедневных галочек на бумажке. Тем не менее с каждым днём и с каждым часом мы становимся должны человеку зарплату. Что отражается в виде периодических начислений. «Начисление зарплаты» такое же в определённом смысле виртуальное действие, как «начисление амортизации», просто зарплате соответствует факт работы, а амортизации — факт устаревания/износа.
Процесс амортизации как функция существует для анализа. Процесс амортизации как периодических записей в реестре не является его неотъемлемой частью, но возникает в бухучёте, поскольку бухгалтерский учёт основан на дискретных периодических записях-проводках.
>заявлять о том, что амортизация описывает какой-то реальный процесс в общем случае неверно.
Соглашусь. Я лишь утверждал, что заявлять будто амортизация не описывает реальный процесс также в общем случае неверно. Она может быть как связана с реальным процессом, так и оторвана от него.
А зачем учитывать поступление денежных средств, которое и так видно в банковской выписке или сумму заработной платы, которая прописана в штатном расписании?
Чтобы можно было собирать агрегирующие показатели по десяткам и сотням A(t) в различных группировках(конкретный производственный цех; отдел; филиал; направление работ). В этом и есть суть учёта: каждый конкретный показатель можно посчитать и без учёта, но чтобы их сложить, отобрать, сравнить их требуется систематизировать.
Значительная часть методов этой систематизации, как отмечено в начале поста, была разработана когда ещё не было компьютеров. Поэтому в общем и целом эти понятия можно рассматривать как наименования аргументов или параметров запроса к базе данных(которая в те времена была на бумаге).
Вот функция A(t) называется «амортизация». Я не говорю, что её сложно посчитать, не назвав «амортизацией»; я говорю, что она существует. Ну и что вообще говоря имея термин «амортизация» мы можем примерно понимать о чём идёт речь, даже когда в другой организации функция будет названа PoraNaSvaku(days)
В пятый раз, пожалуйста: для амортизации как понятия коррелирует. Причём именно со сроком эксплуатации, как владелец организации его понимает во временном или в натуральном выражении.
Да, требования налогового учёта или чего-то ещё могут сдвигать амортизацию за пределы этого срока. Это не означает, что амортизация как понятие не применима за пределами налогового учёта.
Потому что когда у нас надо обсчитывать сотни и тысячи ОС в разрезе десятков направлений деятельности, то неплохо бы все эти вопросы как-то систематизировать. Систематизацией таких вещей в общем и занимается бухгалтерский учёт. В частности при помощи понятия амортизации.
>Нет смысла продавать что-то за бесценок, если это что-то генерирует положительный денежный поток превышающий его текущую стоимость.
Эмм… а как это сравнивать? Расстояние со скоростью (стоимость с потоком) сравнивается только при добавлении фактора времени. Вот для превращение стоимости оборудование в поток его обесценивания путём деления на предполагаемый срок полезного использования и будет одним из возможных смыслов амортизации. Более простым, чем учёт для налоговой, на мой взгляд.
Соответственно получение потока для сравнения с потоком и поможет принять решение. Потому что сто тысяч морских миль с десятью узлами не сравниваются.
>Но эту точку зрения вы не обосновали.
Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
>Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»?
Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена. Мы делаем на нём болты — столько сколько продаём, а продаём — сколько у нас покупают. Вопрос: успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства? Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка?
А то, если у нас продажа болтов зарплату рабочего, материалы, аренду и пр. отбивают (вроде поток денежный в плюсе), но оставшихся денег не хватает ни на что и, когда станок сломается, итоговый результат с учётом его покупки будет отрицательным.
Вообще-то нет, управление организацией не сводится к управлению денежным потоком.
После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Иначе у нас инвестиции превращаются в выбрасывание денег.
Нет, себестоимость совершенно необязательна для существования амортизации.
Погранзастава, не производящая ровным счётом ничего, тоже имеет ОС и тоже их амортизирует. И также может амортизировать ОС какой-нибудь фонд борьбы с раком. Например, чтобы объяснить источнику пожертвований почему мы уже третий стол в бухгалтерию закупаем (вот видите, у нас столы изнашивались/амортизировались уже 8 лет, пора менять).
Конечно без себестоимости потребность в понятии амортизации меньше и можно её не считать. Но это не повод утверждать, что за пределами себестоимости амортизации не существует.
Первые два пункта в основном не про то как считать, а про то как не считать. Особенно если рассмотреть пример с машиной. Конечно можно не вести учёт вообще, в ситуации «анархии» нас ничто к учёту не обязывает. Но если учёт сложный, то оно потребуется.
Формализацией и апроксимацией последних двух пунктов и является амортизация.
Грубая и далёкая от оригинала апроксимация? Да.
Не существует за пределами налоговой отчётности? Нет.
Я не говорю, что амортизация нужна везде и всегда. Я только говорю, что понятие амортизации шире чем её применение при сдаче налоговой отчётности. И оттого возражаю, когда некоторое понимание амортизации объявляется «невозможным» по причине противоречия требованиям налоговой.
Обратите внимание, что вы продолжаете описывать амортизацию в рамках установленных законом ограничений, предполагая что бухучёт есть исключительно порождение законов. Именно это и есть, то что я называю «нездоровым», а отнюдь не несоответствие требований ОКОФ времени износа.
Бухучет существует вне зависимости от того, прописан он в законах или нет. Если представить на минутку, что мы не платим никуда налогов и не сдаём никуда отчётность — бухучёт всё ещё останется. И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости? При помощи той же амортизации. Высчитывая её исходя из понимаемого в каждом конкретном случае срока полезного использования. В том числе понимая его как время от покупки до выбрасывания.
Конечно «износ» — это очень грубое, первое упрощение понятия амортизации. Амортизация также пытается вобрать в себя такие вещи как «моральное устаревание», «востребованность» и так далее. Но говорить, что амортизация не имеет отношения к износу это как говорить, что комплексные числа не имеют отношения к числу яблок на столе(hint: целые числа — часть множества комплексных).
То есть глубина паранойи определяется не потребителем, не источником, а интернетом как таковым. При этом тенденция в том, что даже источник не должен определять необходимо ли что либо шифровать или нет. Ну… мне не нравится, когда кто бы то ни было диктует что бы то ни было. Даже если это благожелательное сообщество беспокоится о моей безопасности.
В данном случае первая претензия моя в первую очередь эстетическая: инструмент (шифрование) используется ненадлежащим образом. При этом происходит определённое навязывание шифрования как вещи столь фундаментальной, как будто ничего вообще без него работать не может (включая запрос аптайма с роутера).
С практической точки зрения… ну я не имел бы ничего против, если бы мой провайдер кешировал у себя популярные ролики с ютуба, чтобы сэкономить на трафике и дать мне более высокую скорость. При этом ему бы не потребовалось получать у Гугла защищённое оборудование, могущее шифровать каждый ролик от имени Гугла. Подпись при этом может браться у Гугла, а вот данные уже локально.
А так-то да. Если бы вопрос стоял остро — так бы и поступал.
А сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому(интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity). Я пытаюсь оппонировать именно позиции «передавать всё-всё-всё по защищённому, всё что не передаётся по защищённому — потенциально скомпрометировано», которую как раз и продвигает Хром.
Вопрос не в том, как ему быть с провайдером, а насколько (и почему) котики требуют шифрования.
Что случится если этот комментарий не будет зашифрован?
Что случится если график в посте не будет зашифрован?
Что случится если лого Яндекса не будет зашифровано?
Современный подход требует шифровать вообще всё (сайт, загружающий нешифрованные картинки помечается как «не совсем безопасный»)
Типа habrahabr — https; habrastorage — http.
Но хотел я сказать не это. Хотел я сказать, что для того, чтобы понять что такое амортизация можно (и нужно) начинать с полезного срока эксплуатации и износа. А «регламентированная» амортизация выводится из этого внесением «регламентов»(НК и ОКОФ). Но амортизация начинается не с регламента и регламент не является её неотъемлемым свойством.
Со станком наоборот: считаем стоимость станка, оцениваем его срок полезного использования (используя ОКОФ, документация производителя, здравый смысл и опыт). Делим одно на другое — получаем амортизацию. Складываем амортизацию с другими расходами на изделие и смотрим окупается у нас изделие или нет.(например при 10 тыс. окупается, а при 5 тыс. — нет)
То же с туалетом. Срок эксплуатации… ну я не особо эксперт в этих делах, но я бы закладывал до первого капитального.
То есть бухучёт по-вашему вообще не нужен? Я вот не представляю, например, организации масштабов хотя бы НИИ, не говоря о чём-то большем, которая могла бы обойтись одной банковской выпиской для управленческих решений.
> учет должен вестись по всем фактам (действиям)
Вот здесь вы резко и принципиально смешали факт и действие. Факт: человек работает. Совершенно не каждый час отмечается в учёте и даже дни собираются в табели обычно пост-фактум, а не в виде ежедневных галочек на бумажке. Тем не менее с каждым днём и с каждым часом мы становимся должны человеку зарплату. Что отражается в виде периодических начислений. «Начисление зарплаты» такое же в определённом смысле виртуальное действие, как «начисление амортизации», просто зарплате соответствует факт работы, а амортизации — факт устаревания/износа.
Процесс амортизации как функция существует для анализа. Процесс амортизации как периодических записей в реестре не является его неотъемлемой частью, но возникает в бухучёте, поскольку бухгалтерский учёт основан на дискретных периодических записях-проводках.
>заявлять о том, что амортизация описывает какой-то реальный процесс в общем случае неверно.
Соглашусь. Я лишь утверждал, что заявлять будто амортизация не описывает реальный процесс также в общем случае неверно. Она может быть как связана с реальным процессом, так и оторвана от него.
Чтобы можно было собирать агрегирующие показатели по десяткам и сотням A(t) в различных группировках(конкретный производственный цех; отдел; филиал; направление работ). В этом и есть суть учёта: каждый конкретный показатель можно посчитать и без учёта, но чтобы их сложить, отобрать, сравнить их требуется систематизировать.
Значительная часть методов этой систематизации, как отмечено в начале поста, была разработана когда ещё не было компьютеров. Поэтому в общем и целом эти понятия можно рассматривать как наименования аргументов или параметров запроса к базе данных(которая в те времена была на бумаге).
Вот функция A(t) называется «амортизация». Я не говорю, что её сложно посчитать, не назвав «амортизацией»; я говорю, что она существует. Ну и что вообще говоря имея термин «амортизация» мы можем примерно понимать о чём идёт речь, даже когда в другой организации функция будет названа PoraNaSvaku(days)
Да, требования налогового учёта или чего-то ещё могут сдвигать амортизацию за пределы этого срока. Это не означает, что амортизация как понятие не применима за пределами налогового учёта.
Потому что когда у нас надо обсчитывать сотни и тысячи ОС в разрезе десятков направлений деятельности, то неплохо бы все эти вопросы как-то систематизировать. Систематизацией таких вещей в общем и занимается бухгалтерский учёт. В частности при помощи понятия амортизации.
Эмм… а как это сравнивать? Расстояние со скоростью (стоимость с потоком) сравнивается только при добавлении фактора времени. Вот для превращение стоимости оборудование в поток его обесценивания путём деления на предполагаемый срок полезного использования и будет одним из возможных смыслов амортизации. Более простым, чем учёт для налоговой, на мой взгляд.
Соответственно получение потока для сравнения с потоком и поможет принять решение. Потому что сто тысяч морских миль с десятью узлами не сравниваются.
Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
>Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»?
Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена. Мы делаем на нём болты — столько сколько продаём, а продаём — сколько у нас покупают. Вопрос: успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства? Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка?
А то, если у нас продажа болтов зарплату рабочего, материалы, аренду и пр. отбивают (вроде поток денежный в плюсе), но оставшихся денег не хватает ни на что и, когда станок сломается, итоговый результат с учётом его покупки будет отрицательным.
После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Иначе у нас инвестиции превращаются в выбрасывание денег.
Погранзастава, не производящая ровным счётом ничего, тоже имеет ОС и тоже их амортизирует. И также может амортизировать ОС какой-нибудь фонд борьбы с раком. Например, чтобы объяснить источнику пожертвований почему мы уже третий стол в бухгалтерию закупаем (вот видите, у нас столы изнашивались/амортизировались уже 8 лет, пора менять).
Конечно без себестоимости потребность в понятии амортизации меньше и можно её не считать. Но это не повод утверждать, что за пределами себестоимости амортизации не существует.
Формализацией и апроксимацией последних двух пунктов и является амортизация.
Грубая и далёкая от оригинала апроксимация? Да.
Не существует за пределами налоговой отчётности? Нет.
Я не говорю, что амортизация нужна везде и всегда. Я только говорю, что понятие амортизации шире чем её применение при сдаче налоговой отчётности. И оттого возражаю, когда некоторое понимание амортизации объявляется «невозможным» по причине противоречия требованиям налоговой.
Бухучет существует вне зависимости от того, прописан он в законах или нет. Если представить на минутку, что мы не платим никуда налогов и не сдаём никуда отчётность — бухучёт всё ещё останется. И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости? При помощи той же амортизации. Высчитывая её исходя из понимаемого в каждом конкретном случае срока полезного использования. В том числе понимая его как время от покупки до выбрасывания.
Конечно «износ» — это очень грубое, первое упрощение понятия амортизации. Амортизация также пытается вобрать в себя такие вещи как «моральное устаревание», «востребованность» и так далее. Но говорить, что амортизация не имеет отношения к износу это как говорить, что комплексные числа не имеют отношения к числу яблок на столе(hint: целые числа — часть множества комплексных).