Яндекс-Браузер к удивлению совсем не относится к «вирусно-распространяемым» софту от Яндекса, сижу на нем уже несколько лет, переехал со старой оперы. Никакой вирусной активности, наоборот очень нравится встроенный Adguard (отключается для нужных сайтов, куча настроек для нестандартных и т.п.).
Через Tor по-прежнему работает, кто не знает ссылку — гуглите «flibusta tor».
Плюс есть несколько зеркал(точнее проксей), подробности на флибусте в топике про закрытие.
Не хватает переключения по одной кнопке в Непрочитанные/Важные как было в старом интерфейсе. В новом нужно тыкать на кнопку «Все письма» и выбирать нужное — два клика, плюс наведение в выпадающем списке.
Очень непонятный механизм управления — практически на каждом шагу приходится некоторое время искать и думать что же тут надо/можно нажать чтобы получить результат.
Я не дизайнер и не могу сказать какие конкретно элементы интерфейса создают такой эффект, но как вы видите из других комментариев, так сайт воспринимаю не только я.
Могу только привести примеры — хочу послушать музыку 90х, выбираю «90х» и сразу затык — куда дальше? После раздумий — нажимаю «Композиции/лучшее» — и опять неясно куда дальше нажать… После раздумий и экспериментов оказывается что нужно опять нажать «лучшее», после чего появляется список песен и не играет — нужно самому ткнуть на любую композицию.
Ну и конечно кнопка «Следующий» при проигрывании трека отлично «заметна и понятна» для новичка.
В том-то и дело что в результате оптимизации работы интерфейса им стало неудобно пользоваться. И в посте есть и про дизайн, просто в тесной сцепке с производительностью, например:
«Комбинация трех этих подходов и относительно фиксированное расположение, высота и ширина визуальных блоков позволяют осуществлять комфортное и крайне быстрое перемещение внутри приложения, формирующееся в привычку.»
Хотя я наверно ошибся с термином, точнее будет сказать не дизайн, а интерфейс — взаимодействие с пользователем.
Несмотря на то что по скорости работы претензий к seesu.me не возникало, дизайн у сайта крайне неудобный и непонятный, можно сказать худший из всех плееров которыми я пользовался.
Ну и соответственно дико видеть какие-то советы по дизайну от автора этого сайта…
8.3 уже стабильна, есть рабочие внедрения в терминальных вариантах, в.т.ч. терминалы на Linux, так что если рассматриваете такой вариант — уже можно пробовать.
Теории нет без практики. С бух. учетом работают люди и все те «недостатки» которые вы заметили нужны людям для удобства их работы.
Вашу же идею для формализации всего и вся можно будет применить только при появлении искусственного интеллекта, который будет заниматься учетом самостоятельно.
1. Хранение товара на складе в разрезе тех свойств которые он физически не имеет (цена, поставщик и т.п.) очень редко используется из-за больших затрат на объем места, программ учета и занятость кладовщиков. Помимо того что для хранения эти свойства не важны, они так же не важны для учета, ибо используете ли вы четкое разделение товара по свойствам или выберите ФИФО или среднее — итоговая себестоимость от этого не измениться. ФИФО/ЛИФО определяет лишь момент списания.
Иначе говоря какой метод списания не выбран, после продажи всего купленного товара себестоимость его будет одна и таже.
С другой стороны в бух. учете не важны именно физические (вес, объем, внешний вид).
Подытожим, если используются методы ФИФО/ЛИФО — себестоимость расчитывается достаточно легко, не требует дополнительных затрат на хранение/кладовщиков/складской учет и логически понятна и бухгалтерам и кладовщикам, если же использовать разделение по свойствам и физическим и учетным, то это потребует больших затрат на место, доп. сотрудников, будет нелогична и непонятна и для бухгалтеров и для кладовщиков, а главное — результат расчета себестоимости в итоге будет одинаков.
Или можно попробовать аналогию — отсортировать массив конечно можно и перебором, но лучше оптмизировать и использовать более подходящие алгоритмы.
2. Например учет расходы будущих периодов имеет и дату возниковения и сроки и амортизацию.
3. Изначально вы говорили что работники в бух. учете не регистрируются, это неверно, т.к. в бух. учете (не проводках) всегда есть записи о приеме на работу и в проводках имется зарегистрированный в учете объект — сотрудник.
Единая методология учета объектов в бух. учете есть, просто, если я правильно понимаю, вам кажется что логичнее было-бы учитывать по-другому, даже несмотря на то что ваш вариант менее удобен, судя по другим пунктам.
4. Сальдо — это разница между дебетом и кредитом, в вашей первой табличке оно отсутствует, хотя в бух. учете имеется всегда.
Баланс — это итог по всем счетам бух. учета и он тут не причем.
Таким образом вы просто не поняли как работает учет объектов в бухгалтерском учете, поэтому и пытаетесь придумать что-то новое, хотя оно уже в нем есть.
Амортизация нужна еще и для ежемесячной/ежеквартальной отчетности, поэтому если вы не будете хранить амортизацию отдельно — не сможете сдать отчетность — итог ведения бух. учета. А вот остаточную стоимость хранить нет смысла — она есть всегда, т.к. равна сальдо по соответствующей аналитике.
По поводу разных языков, дело в том что последний десяток лет я как раз работаю стыкуя программы учета с самим бух. учетом и вижу что вы не точно понимая объект критики пытатесь посоветовать что-то в этом поменять и этим можете смутить людей которые не в курсе бух. учета. Поэтому я пытаюсь донести до вас эту мысль, по-разному её формулируя.
Кроме того, меня абсолютно не напрягает спор без перехода на личности, поэтому всегда готов продолжить :)
1. Что-то у вас перепуталось. Партия товара не идентифицирует конкретный объект на складе, она нужна только для сохранения аналитики (чаще всего стоимости) товара. Иначе говоря, придя на склад вы не сможете разделить лежащий кучей одинаковый товар по цене поставщика, может быть совершенно одинаковый товар, но взятый у разных поставщиков с разной стоимостью.
Соответственно при списании товара со склада нужно определиться с порядком выбора списываемой партии — именно этот порядок указывается в учетной политике и может быть ФИФО, ЛИФО, по-среднему или с выбором партии вручную.
Тем не менее, какую вы партию бы не выбрали, со склада возмут первый попавшийся товар в нужном количестве.
Вопрос учета на складе товара с точностью до свойств отдельного объекта применяется редко и только в управленческом учете, для бухгалтерского учета это не имеет значения, т.к. см. выше.
2. Обе даты и регистрируются, и это стандартная практика в программах учета, учитывается срок и параметры амортизации.
3. Единая методология есть, но описана она достаточно формально, что позволяет широко варьировать точность и сложность учета для разных организаций. Например малые организации часто учитывают товар очень обще — например «кровать», «дверь», точнее им не нужно, а некоторые с точностью до цвета/серии/сроков — и все эти варианты можно отразить в обычной проводке с помощью аналитик.
Если же уточнять методологию с точностью до правил указания аналитики — она будет негибкой и неприемлимой для некоторых организаций.
4. Бухгалтерские регистры построены таким образом чтобы итог по счету (включая отбор по аналитке) должен быть всегда расчитан, поэтому в первой ваше табличке нужно добавить итог: — 85 рублей, иначе говоря вы всегда знаете остаточную стоимость.
Вторая же табличка для бух. учета бесполезна, т.к. из неё нельзя понять какая была амортизация за какой-либо период или может было дооборудование.
Надеюсь понятно объяснил бесполезность вашей идеи с полем :)
Проблема в том что вы придумали какого-то сферический бухгалтерский учет, придумали к нему ограничения и накладываете их на реальную жизнь.
Красота реального бух. учета в том организация самостоятельно определяет параметры аналитического учета для любых объектов учета и может их учитывать на бумажке или в программе учета.
Ограничения бух. учета имеются в синтетике — плане счетов, да и то частично — никто не помешает заводить субсчета. Ну и готовые формулы расчета амортизации для некоторых объектов.
1. Именно так в жизни и происходит, руководитель вместе с гл. бухом решают как они будут расчитывать себестоимость и прописывают себе в учетную политику. Могут прописать ФИФО/ЛИФО/Среднему, могут вручную выбирать партии. Причем могут делать это как на бумажке, так и в какой-либо программе. Так что никаких ограничений бух учет по этому пункту не имеет.
2. Возникновение обязательства и его сроки это взаимосвязанные события и логично регистрировать их по дате первого наступившего из двух событий — что всегда будет дата возникновения. Так же бух. учет никак не запрещает в момент возникновения записать параметры обязательства для упрощения дальнейших расчетов по погашению.
3. Про проводки я ничего не говорил. Я говорил что для бух. учета важно учитывать операции приема на работу, чтобы проводки по зарплате учитывали актуальных сотрудников. Объясняю как это учитываются в бух. учете — 1) если на соот. бумажке ведется список актуальных сотрудников — туда добавляется новая строка с сотрудником или вычеркивается старая 2) если в соот. программе — вызывается соот. операция
Бух. учет не запрещает учитывать любым способом любые дополнительные данные, особенно те которые нужны для проводок.
4. Нет никакого просто изменения поля, ничего само по себе не происходит, не может товар лежащий на складе просто так поменять цену, нужно основание. Обычное изменение поля с ценой, без оснований — не является достаточным для отражения в бух. учете, нужен именно новый объект учета…
1. Софт нужен лишь для автоматизации бух. учета. Вести аналитику бухгалтерских операций можно и на бумажке, просто сильно неудобно.
Неважно что есть на складе, в рамках бух. учета на складе будут учитываться объекты, сгруппированные по стоимости (или партии или по любой другой нужной аналитике)
ФИФО, ЛИФО не забудут никогда, т.к. это и есть виды возможностей учета разной стоимости одного и того же вида товаров.
2. Повторюсь — софт — это способ автоматизации и не является чем-то самостоятельным по учету.
3. Прием/увольнение нужно не для содержимого проводки, а для проверки нужно ли её вообще создавать. Иначе говоря без приема на работу не может быть проводки по 70му счету, т.к. нет оформленного сотрудника.
4. Каждое запомненное состояние изменения поля и есть регистрация этого изменения. Каждое изменение цены или стоимости происходит не просто так, а по факту какой-то бухгалтерской операции — поступление товара с новой ценой, переоценка товара на складе при инвентаризации, поступление доп. расходов и т.п. — поэтому удобнее привязывать каждое изменение поля цены к какой-либо конкретной операции.
Бухгалтерии в чистом виде — только синтетический количественно-суммовой учет — практически не встречается в реальной жизни, бухгалтеру всегда нужны дополнительные сведения — аналитика — для последующей сдачи налоговой/бухгалтерской/статистической отчетности, для отчета перед руководителем, да даже для банальной проверки заполнения первичных документов.
1. Неверно, во многих учетных программах есть разделение объектов по стоимости, в основном через дополнительную аналитику партий объекта. (Например сч. 41, аналитики Номенклатура, Склад, Партии), партия — это сохранение даты поступления объекта и других его свойств, в.т.ч. стоимости
2. «Не должно быть регистрации» — это совсем непродуманное высказывание, что-бы что-то учитывать, нужно это зарегистрировать. Обязательства имеют не только сроки выполнения, но и момент их возникновения — именно он и регистрируется. Кроме того в учете есть возможность указывать дату/сроки выполнения и способы расчета — например амортизацию.
3. Работники вообще не в тему. В бух. учете они отлично регистрируются как отдельные объекты — сотрудники организации, имют кучу нужных для учета параметров вроде табельного номера. Кроме того имеется обязательные в учете операции с объектами — прием/увольнение на/с работы.
4. Два поля подойдут если изменение цены было один раз, что вряд ли бывает на практике. Для учета каждого изменения нужно каждое изменение сохранить… Для бух. учета это необходимо для точного расчета себестоимости.
Эм, ну думаю сложно коренным образом изменить игру которой более 10ти лет не потеряв той самой основной базы пользователей.
Поэтому, думаю Близзард и делает одновременно и какую-то новую игру (Титан) и продолжают наполнять контентом не меняя стиль игры в WoW и например выпускают карточную онлайн игру Hearthstone: Heroes of Warcraft, то есть работают в разных направлениях.
Тем более каноны MMORPG понятие очень расплывчатое, более того, я бы даже сказал что эти каноны по-большей части-то определялись как раз Близзардом :)
Начнем с того что основная база игроков WoW это как раз казуальные игроки которые только приветствуют увеличение доступного для них контента, поэтому WoW никак не подходит в качестве аргумента против этого пункта статьи.
Топовых игроков — которым нужен самый сложный уровень игры — несколько процентов, но и их не обходят вниманием, сложные режимы рейдов продолжают выпускать.
Кроме того, не «упростили очень сильно», а добавили много контента, существенная часть которого доступна для казуалов, при этом сбалансировали достаточно хорошо, так что каждый может найти подходящую для себя сложность.
Пример: Групповые подземелья: Сценарии (казуал)/Героики(обычная сложность)/Режимы испытания(высокая сложность или возьмем рейды — есть лфр (для казуалов)/обычный режим(средняя сложность/героический режим(высокая сложность).
Прокачка очень интересная и достаточно сложная для тех кто качается в первый раз, а вот как раз для тех кто качает себе альтернативного персонажа сделано ускорение прокачки через фамильные вещи/бое предметы полученные основным персонажем.
И например мне, игроку с пятилетним стажем, пока нравится тенденция изменений в WoW, как в сложных рейдах, так и в остальных моментах игры.
Плюс есть несколько зеркал(точнее проксей), подробности на флибусте в топике про закрытие.
Я не дизайнер и не могу сказать какие конкретно элементы интерфейса создают такой эффект, но как вы видите из других комментариев, так сайт воспринимаю не только я.
Могу только привести примеры — хочу послушать музыку 90х, выбираю «90х» и сразу затык — куда дальше? После раздумий — нажимаю «Композиции/лучшее» — и опять неясно куда дальше нажать… После раздумий и экспериментов оказывается что нужно опять нажать «лучшее», после чего появляется список песен и не играет — нужно самому ткнуть на любую композицию.
Ну и конечно кнопка «Следующий» при проигрывании трека отлично «заметна и понятна» для новичка.
«Комбинация трех этих подходов и относительно фиксированное расположение, высота и ширина визуальных блоков позволяют осуществлять комфортное и крайне быстрое перемещение внутри приложения, формирующееся в привычку.»
Хотя я наверно ошибся с термином, точнее будет сказать не дизайн, а интерфейс — взаимодействие с пользователем.
Ну и соответственно дико видеть какие-то советы по дизайну от автора этого сайта…
Вашу же идею для формализации всего и вся можно будет применить только при появлении искусственного интеллекта, который будет заниматься учетом самостоятельно.
Иначе говоря какой метод списания не выбран, после продажи всего купленного товара себестоимость его будет одна и таже.
С другой стороны в бух. учете не важны именно физические (вес, объем, внешний вид).
Подытожим, если используются методы ФИФО/ЛИФО — себестоимость расчитывается достаточно легко, не требует дополнительных затрат на хранение/кладовщиков/складской учет и логически понятна и бухгалтерам и кладовщикам, если же использовать разделение по свойствам и физическим и учетным, то это потребует больших затрат на место, доп. сотрудников, будет нелогична и непонятна и для бухгалтеров и для кладовщиков, а главное — результат расчета себестоимости в итоге будет одинаков.
Или можно попробовать аналогию — отсортировать массив конечно можно и перебором, но лучше оптмизировать и использовать более подходящие алгоритмы.
2. Например учет расходы будущих периодов имеет и дату возниковения и сроки и амортизацию.
3. Изначально вы говорили что работники в бух. учете не регистрируются, это неверно, т.к. в бух. учете (не проводках) всегда есть записи о приеме на работу и в проводках имется зарегистрированный в учете объект — сотрудник.
Единая методология учета объектов в бух. учете есть, просто, если я правильно понимаю, вам кажется что логичнее было-бы учитывать по-другому, даже несмотря на то что ваш вариант менее удобен, судя по другим пунктам.
4. Сальдо — это разница между дебетом и кредитом, в вашей первой табличке оно отсутствует, хотя в бух. учете имеется всегда.
Баланс — это итог по всем счетам бух. учета и он тут не причем.
Таким образом вы просто не поняли как работает учет объектов в бухгалтерском учете, поэтому и пытаетесь придумать что-то новое, хотя оно уже в нем есть.
Амортизация нужна еще и для ежемесячной/ежеквартальной отчетности, поэтому если вы не будете хранить амортизацию отдельно — не сможете сдать отчетность — итог ведения бух. учета. А вот остаточную стоимость хранить нет смысла — она есть всегда, т.к. равна сальдо по соответствующей аналитике.
По поводу разных языков, дело в том что последний десяток лет я как раз работаю стыкуя программы учета с самим бух. учетом и вижу что вы не точно понимая объект критики пытатесь посоветовать что-то в этом поменять и этим можете смутить людей которые не в курсе бух. учета. Поэтому я пытаюсь донести до вас эту мысль, по-разному её формулируя.
Кроме того, меня абсолютно не напрягает спор без перехода на личности, поэтому всегда готов продолжить :)
1. Что-то у вас перепуталось. Партия товара не идентифицирует конкретный объект на складе, она нужна только для сохранения аналитики (чаще всего стоимости) товара. Иначе говоря, придя на склад вы не сможете разделить лежащий кучей одинаковый товар по цене поставщика, может быть совершенно одинаковый товар, но взятый у разных поставщиков с разной стоимостью.
Соответственно при списании товара со склада нужно определиться с порядком выбора списываемой партии — именно этот порядок указывается в учетной политике и может быть ФИФО, ЛИФО, по-среднему или с выбором партии вручную.
Тем не менее, какую вы партию бы не выбрали, со склада возмут первый попавшийся товар в нужном количестве.
Вопрос учета на складе товара с точностью до свойств отдельного объекта применяется редко и только в управленческом учете, для бухгалтерского учета это не имеет значения, т.к. см. выше.
2. Обе даты и регистрируются, и это стандартная практика в программах учета, учитывается срок и параметры амортизации.
3. Единая методология есть, но описана она достаточно формально, что позволяет широко варьировать точность и сложность учета для разных организаций. Например малые организации часто учитывают товар очень обще — например «кровать», «дверь», точнее им не нужно, а некоторые с точностью до цвета/серии/сроков — и все эти варианты можно отразить в обычной проводке с помощью аналитик.
Если же уточнять методологию с точностью до правил указания аналитики — она будет негибкой и неприемлимой для некоторых организаций.
4. Бухгалтерские регистры построены таким образом чтобы итог по счету (включая отбор по аналитке) должен быть всегда расчитан, поэтому в первой ваше табличке нужно добавить итог: — 85 рублей, иначе говоря вы всегда знаете остаточную стоимость.
Вторая же табличка для бух. учета бесполезна, т.к. из неё нельзя понять какая была амортизация за какой-либо период или может было дооборудование.
Надеюсь понятно объяснил бесполезность вашей идеи с полем :)
Красота реального бух. учета в том организация самостоятельно определяет параметры аналитического учета для любых объектов учета и может их учитывать на бумажке или в программе учета.
Ограничения бух. учета имеются в синтетике — плане счетов, да и то частично — никто не помешает заводить субсчета. Ну и готовые формулы расчета амортизации для некоторых объектов.
1. Именно так в жизни и происходит, руководитель вместе с гл. бухом решают как они будут расчитывать себестоимость и прописывают себе в учетную политику. Могут прописать ФИФО/ЛИФО/Среднему, могут вручную выбирать партии. Причем могут делать это как на бумажке, так и в какой-либо программе. Так что никаких ограничений бух учет по этому пункту не имеет.
2. Возникновение обязательства и его сроки это взаимосвязанные события и логично регистрировать их по дате первого наступившего из двух событий — что всегда будет дата возникновения. Так же бух. учет никак не запрещает в момент возникновения записать параметры обязательства для упрощения дальнейших расчетов по погашению.
3. Про проводки я ничего не говорил. Я говорил что для бух. учета важно учитывать операции приема на работу, чтобы проводки по зарплате учитывали актуальных сотрудников. Объясняю как это учитываются в бух. учете — 1) если на соот. бумажке ведется список актуальных сотрудников — туда добавляется новая строка с сотрудником или вычеркивается старая 2) если в соот. программе — вызывается соот. операция
Бух. учет не запрещает учитывать любым способом любые дополнительные данные, особенно те которые нужны для проводок.
4. Нет никакого просто изменения поля, ничего само по себе не происходит, не может товар лежащий на складе просто так поменять цену, нужно основание. Обычное изменение поля с ценой, без оснований — не является достаточным для отражения в бух. учете, нужен именно новый объект учета…
Неважно что есть на складе, в рамках бух. учета на складе будут учитываться объекты, сгруппированные по стоимости (или партии или по любой другой нужной аналитике)
ФИФО, ЛИФО не забудут никогда, т.к. это и есть виды возможностей учета разной стоимости одного и того же вида товаров.
2. Повторюсь — софт — это способ автоматизации и не является чем-то самостоятельным по учету.
3. Прием/увольнение нужно не для содержимого проводки, а для проверки нужно ли её вообще создавать. Иначе говоря без приема на работу не может быть проводки по 70му счету, т.к. нет оформленного сотрудника.
4. Каждое запомненное состояние изменения поля и есть регистрация этого изменения. Каждое изменение цены или стоимости происходит не просто так, а по факту какой-то бухгалтерской операции — поступление товара с новой ценой, переоценка товара на складе при инвентаризации, поступление доп. расходов и т.п. — поэтому удобнее привязывать каждое изменение поля цены к какой-либо конкретной операции.
Бухгалтерии в чистом виде — только синтетический количественно-суммовой учет — практически не встречается в реальной жизни, бухгалтеру всегда нужны дополнительные сведения — аналитика — для последующей сдачи налоговой/бухгалтерской/статистической отчетности, для отчета перед руководителем, да даже для банальной проверки заполнения первичных документов.
2. «Не должно быть регистрации» — это совсем непродуманное высказывание, что-бы что-то учитывать, нужно это зарегистрировать. Обязательства имеют не только сроки выполнения, но и момент их возникновения — именно он и регистрируется. Кроме того в учете есть возможность указывать дату/сроки выполнения и способы расчета — например амортизацию.
3. Работники вообще не в тему. В бух. учете они отлично регистрируются как отдельные объекты — сотрудники организации, имют кучу нужных для учета параметров вроде табельного номера. Кроме того имеется обязательные в учете операции с объектами — прием/увольнение на/с работы.
4. Два поля подойдут если изменение цены было один раз, что вряд ли бывает на практике. Для учета каждого изменения нужно каждое изменение сохранить… Для бух. учета это необходимо для точного расчета себестоимости.
Поэтому, думаю Близзард и делает одновременно и какую-то новую игру (Титан) и продолжают наполнять контентом не меняя стиль игры в WoW и например выпускают карточную онлайн игру Hearthstone: Heroes of Warcraft, то есть работают в разных направлениях.
Тем более каноны MMORPG понятие очень расплывчатое, более того, я бы даже сказал что эти каноны по-большей части-то определялись как раз Близзардом :)
Топовых игроков — которым нужен самый сложный уровень игры — несколько процентов, но и их не обходят вниманием, сложные режимы рейдов продолжают выпускать.
Кроме того, не «упростили очень сильно», а добавили много контента, существенная часть которого доступна для казуалов, при этом сбалансировали достаточно хорошо, так что каждый может найти подходящую для себя сложность.
Пример: Групповые подземелья: Сценарии (казуал)/Героики(обычная сложность)/Режимы испытания(высокая сложность или возьмем рейды — есть лфр (для казуалов)/обычный режим(средняя сложность/героический режим(высокая сложность).
Прокачка очень интересная и достаточно сложная для тех кто качается в первый раз, а вот как раз для тех кто качает себе альтернативного персонажа сделано ускорение прокачки через фамильные вещи/бое предметы полученные основным персонажем.
И например мне, игроку с пятилетним стажем, пока нравится тенденция изменений в WoW, как в сложных рейдах, так и в остальных моментах игры.