Comments 182
Чисто подход 1С-ника. К программированию сие изделие имеет малое отношение. Больше портит самих программистов — полета мысли ноль целых, ноль десятых. Когда пытаются всучить в аптеки на розницу систему на базе 1С — я вою тихо. Для аптек 1С практически не подходит.
А в силе она у нас из-за того что бухгалтерия — основное что требует государство, столько времени уходит на бумажки — жесть просто.
А статью лучше назвать как-нибудь "бухучет для сопровожденцев 1С". От программистов там мало что осталось.
Разве автор писал что-то про аптеки?..
Про них нет, но зная как 1С-ники всовывают свою 1С во все… хм, области применения...
Дело в том что программист умирает в человеке когда он видит СКОЛЬКО можно заработать на 1С просто перепродав ее. При всем этом — потолок 1С-ника это столица, дальше ему ехать некуда (ну разве что в Украину).
Другие программы бухгалтерские — тренд тот же. Они воюют за рынок пользователей с 1С. Франы 1С — ой-ой-ой… Ну это не программисты. Я не буду спорить что ребята бывают толковые, но толковые уезжают в Москву.
Собственно коммент был к тому что 1С-ник это не программист, а внедренец/обновитель/исправленец косяков. Любой кто работает с 1С знает про бухгалтерию достаточно чтобы понять бухгалтера (во всяком случае толковый человек точно знает).
Т.е. если я разрабатываю структуру БД (таблицы, поля, типы данных), пишу алгоритмы, по которым эти данные в различных полях и таблицах друг с другом взаимодействуют, рисую интерфейс, который даёт пользователю возможность удобно редактировать и работать с этими данными — я не программист?
Несмотря на то что сам 1сник — имхо, да, частично это именно так. 1сник кроме программирования (причем на упрощенном языке не поддерживающим многие интересные и полезные концепции) занимается задачами аналитика, DBA, иногда консультанта, и хорошо если это все. А то ведь бывает что и сервера непосредственно администрирует.
Это и про многих других можно сказать. Ничего уникального для 1С в этом нет.
На самом деле полностью с этим согласен, просто в 1с это распространено заметно больше. Как и в вебе, пусть там немного по другому. Еще одна важная проблема в 1с — почти полное отсутствие пересечения с остальным сообществом программистов, чтобы перенимать подходы, технологии и т.п. И соответственно сложилась культура когда например знание каких то деталей работы платформы, предметной области и конкретных прикладных решений, получение сертификатов от 1с (даже если знания которые нужны для сертификата вообще не по профилю человека) — считается гораздо более важным чем принципов написания хорошего кода (SOLID, DRY, KISS и т.п.), абсолютное игнорирование хороших практик (отсутствие тестов считается нормой даже если продукт на 1с разрабатывается с нуля и планируется его поддержка, отсутствие обмена опытом и исправления косяков через код ревью и т.п.), про алгоритмы и всякое такое и не вспоминаю. Хорошо это или плохо — другой вопрос, поскольку судя по количеству вакансий и специалистов деньги приносит неплохие, просто от программирования в классическом виде — это уже заметно отошло.
А что с аптеками-то не так? Чем от просто торговой точки отличается?
Вот Вам основные отличия.
- Ежедневный приход в накладных порядка 100-200 позиций
- Номенклатурный список на складе ОДНОЙ точки должен быть не менее 5-6 тысяч наименований. Рекордсмен у меня 10 тысяч наименований
- Расчет цен идет достаточно противный — у каждой позиции есть несколько входящих цен (цена изготовителя, цена реестра, цена поставщика), в зависимости от них считается максимальная цена. Большое количество колонок в накладной налагает определенные ограничения на табличную часть. Ее достаточно сложно сделать вменяемой
- Заказ товаров делается в прайс-листах общим обьемом около 50-80 тысяч позиций. Наименования нестандартизированы.
- У многих товаров есть сопутствующие товары которые было бы неплохо подсвечивать.
Вот все что слету вспомнил. Главный напряг всегда был — количество на складе, плюс объем прайсов поставщиков. поставщиков порядка 10-20 обычно в аптеке, крупняка из них 5-6. По отдельности каждый вопрос тьфу. Но когда их начинают реализовывать — о боже ты мой...
Это из личной практики — 1С-ка в аптеках практически не приживается. Пинать меня типа "да ты не знаешь 1С" — без проблем. Пройдите по аптекам и узнайте что у них стоит. 1С — мало где. Может причина не в моих знаниях?
P.S. Из практики. Есть такая софтина Эприка. У них была розничная программа на базе 1С… во второй версии они ее поменяли, и от 1С ушли.
М-Аптеку от SIA Int не застали? Ещё когда она с досовским интерфейсом была. 2008г вроде
1,2. Автозапчасти — номенклатурный список на складе супермаркета 20+К позиций. БТЭ — 12+К позиций. Продовольственный супермаркет районного уровня — 12-20К позиций.
Кстати, я сейчас работаю на производстве с 12+К позиций производимой продукции, ввод в производство (а это штук 5 единиц оснастки на каждую позицию) — 50-70 единиц в месяц.
3. Рост (и падение) цен в БТЭ — ежедневные корректировки по баксу и бирже. Есть несколько типов цен для клиентов.
4. набор прайсов в автозапчастях — несколько МИЛЛИОНОВ позиций. Названия нестандартизованы.
5. гы. где-то не так?
Количество поставщиков 10-20 для продуктовых супермаркетов несерьезно, счет может идти на сотни. А меньше пары десятков я просто не очень представляю где может встретится.
Кстати, я сейчас работаю на производстве с 12+К позиций производимой продукции, ввод в производство (а это штук 5 единиц оснастки на каждую позицию) — 50-70 единиц в месяц.
3. Рост (и падение) цен в БТЭ — ежедневные корректировки по баксу и бирже. Есть несколько типов цен для клиентов.
4. набор прайсов в автозапчастях — несколько МИЛЛИОНОВ позиций. Названия нестандартизованы.
5. гы. где-то не так?
Количество поставщиков 10-20 для продуктовых супермаркетов несерьезно, счет может идти на сотни. А меньше пары десятков я просто не очень представляю где может встретится.
- По поводу автозапчастей — да, согласен. Там даже больше их может быть. но как показывает мой наблюдательный опыт — специфика торговли автозапчастями и лекарствами различается очень и очень кардинально. Как и скорость ожидания товара покупателем. Продовольственный супермаркет — аналогично — специфика, маржа другая. Скорость обслуживания покупателя другая. Да — другие заморочки есть, тут соглашусь.
- не в курсе, потому не буду комментировать. Правда сомневаюсь что на бирже используют 1С.
- Прайсы в запчастях (опять же). Что-то гложет меня сомнение что там идет подбор по наименованию и просто так. Да — мелкие расходники думаю так и набираются. Как бы спорить не буду по поводу того как работают заказы в автозапчастях, но что-то там сводных программ с прайсами я не наблюдал (интересоваться смысла не вижу — не мой рынок. Если они там есть — напишите, интересно. В аптеках — сводники на каждом шагу (регионе)).
Поставщики для продуктовых супермаркетов — да не вопрос. но там опять же (ух… опять...) специфика — один и тот же товар закупается у одного и того же поставщика. И цены сравниваются редко. Мы пытались со сводником вылезти в продуктовые магазины — не пошло.
1. и что там кардинального? Ну, скажем, я строил магазины БТЭ с 12+К SKU, основная выдача — со склада, время ожидания — единицы минут. Что в аптеке так отличается, что меня устраивала 1с, а их — нет?
2. не на бирже, а биржевые товары. Цена на быстродвигающиеся товары типа оперативы может меняться дважды на день, причем иногда значительно. Для БТЭ нормальная оборачиваемость склада — месяц, на биржевых товарах — неделя максимум, цена должна быть актуальной. И да, не актуализировал цену на проц — он вышел на 5% из рынка — завис на лишнюю неделю — за это время подешевел на 10% — ушел в минус от входящей цены — твои потери 5 тыр на единице, на складе 15 единиц, итого 75 тыр за неделю. Такое в аптеках бывает?
3. а как без сводных жить на рынке с миллионами единиц? У каждого дистриба свой формат, причем иногда несколько форматов по вендорам, все это должно биться с ОЕМами (но не всегда бьется), ОЕМы должны биться с каталогами оригиналов (но опять не всегда бьются), каталоги — с реальными авто (опять же не всегда).
4. в случае крупного супермаркета — да, один товар у одного поставщика. Только де-факто, для супермаркета «молоко А 2,5% РРЦ 60 руб» — это полный аналог «молока Б 2,5% РРЦ 60 руб» от другого поставщика. SKU одно, место на полке ограничено. Так что работа с поставщиками сложней на порядок.
2. не на бирже, а биржевые товары. Цена на быстродвигающиеся товары типа оперативы может меняться дважды на день, причем иногда значительно. Для БТЭ нормальная оборачиваемость склада — месяц, на биржевых товарах — неделя максимум, цена должна быть актуальной. И да, не актуализировал цену на проц — он вышел на 5% из рынка — завис на лишнюю неделю — за это время подешевел на 10% — ушел в минус от входящей цены — твои потери 5 тыр на единице, на складе 15 единиц, итого 75 тыр за неделю. Такое в аптеках бывает?
3. а как без сводных жить на рынке с миллионами единиц? У каждого дистриба свой формат, причем иногда несколько форматов по вендорам, все это должно биться с ОЕМами (но не всегда бьется), ОЕМы должны биться с каталогами оригиналов (но опять не всегда бьются), каталоги — с реальными авто (опять же не всегда).
4. в случае крупного супермаркета — да, один товар у одного поставщика. Только де-факто, для супермаркета «молоко А 2,5% РРЦ 60 руб» — это полный аналог «молока Б 2,5% РРЦ 60 руб» от другого поставщика. SKU одно, место на полке ограничено. Так что работа с поставщиками сложней на порядок.
А какое отношение аптека имеет к статье и статья к 1С?
Тем более в статье расказан бухучет предприятия. А есть ещё бух учет банка, там есть свои особенности.
Но как статья связана с вашей нелюбовью в 1С непонятно
Тем более в статье расказан бухучет предприятия. А есть ещё бух учет банка, там есть свои особенности.
Но как статья связана с вашей нелюбовью в 1С непонятно
А что с аптеками-то не так? Чем от просто торговой точки отличается?
Минимальными отличиями:
1) Феерический ассортимент на достаточно малой площади
2) Наличием ЖНЛВП и особенностями учета. В частности, для ЖНЛВП регламентирована максимальная наценка.
Есть еще одна фигня про которую часто забывают — зарегулированность отчетами. Часто на заведующую навешано государством мал-мала-больше отчетов для сдачи в определенные сроки. Есть еще много фигни мелкой которая напрягает (совпадение заводских штрих-кодов у одного производителя, отчеты по сериям и прочее).
Со слов все делается легко, но в реальности — сложно увидеть идеальное решение.
Есть еще одна фигня про которую часто забывают — зарегулированность отчетами. Часто на заведующую навешано государством мал-мала-больше отчетов для сдачи в определенные сроки.
Для этих целей есть внедренцы. Если типовое решение не позволяет сформировать отчет, то нужно обращаться к внедренцам. Если внедренцы сосут мозг — нужно менять внедренцев.
Есть еще много фигни мелкой которая напрягает (совпадение заводских штрих-кодов у одного производителя, отчеты по сериям и прочее).
Вообще не вижу проблемы. Совпал штрих-код — перебить свой вопрос пары минут.
Рабочие вопросы везде возникают. Не понимаю чем тут конкретно 1с не угодила? Или отказавшись от 1с, у вас автоматически заводы угадывают правильные штрихкоды?
А что с аптеками-то не так? Чем от просто торговой точки отличается?
Принципиально ничем не отличается. Отсутствует весовой товар, наличествует адресное хранение, партионный учет, ограничение отпуска товара определенным категориям граждан (рецептурные препараты). Жесткие требования к ценообразованию, сертификатам и срокам годности. Остальные навороты — исключительно эргономические бантики и специализированные отчетные формы.
Но ведь в торговых точках все тоже самое :)
Адресное хранение — торговые агенты (у более богатых поставщиков мерчи) проверяют наличие своего товара на определенной полочке в определенном порядке. В сигаретных отделах каждая пачка буквально в своей ячейке и опытный продавец берет товар не глядя.
Ограничение отпуска — продажа алкоголя при наличии паспорта или водительских прав.
Требования к ценообразованию — в продаже табачной и алкогольной продукции нельзя указывать цены с потолка, они регулируются законодательно (гуглите МРЦ).
Сертификаты качества и сроки годности (партионный учет) — архиважные элементы при торговле скоропортом таким как молочка и мясные изделия. Это вам не активированный уголь с вьетнамской звездочкой :)
Адресное хранение — торговые агенты (у более богатых поставщиков мерчи) проверяют наличие своего товара на определенной полочке в определенном порядке. В сигаретных отделах каждая пачка буквально в своей ячейке и опытный продавец берет товар не глядя.
Ограничение отпуска — продажа алкоголя при наличии паспорта или водительских прав.
Требования к ценообразованию — в продаже табачной и алкогольной продукции нельзя указывать цены с потолка, они регулируются законодательно (гуглите МРЦ).
Сертификаты качества и сроки годности (партионный учет) — архиважные элементы при торговле скоропортом таким как молочка и мясные изделия. Это вам не активированный уголь с вьетнамской звездочкой :)
К программированию сие изделие имеет малое отношение
Взгляд человека, далекого от 1с. А вообще, вопрос не в том, присутствует в изделии программирование или нет, а в том, насколько хорошо оно решает поставленные задачи. 1С — решает.
Когда пытаются всучить в аптеки на розницу систему на базе 1С — я вою тихо. Для аптек 1С практически не подходит.
Есть аргументы или просто «ни асилил»?
Внедрял в аптеку 1С: Аптека на базе 1С Розницы — никаких проблем не заметил, что оно туда «вообще не подходит».
А в силе она у нас из-за того что бухгалтерия — основное что требует государство, столько времени уходит на бумажки — жесть просто.
Это тоже взгляд человека бесконечно далекого от 1с. Кроме бухгалтерии, которую требует государство, есть еще управленческий учет, с которым 1с прекрасно справляется. Даже SAP кое-где двигает.
От программистов там мало что осталось.
В мире 1с действительно прорва сопровожденцев, что естественно, потому как порог входа ниже. Что 1) не является недостатком, а наоборот является достоинством. 2) программисты (как и соответствующие задачи для них) имеют место быть и в мире 1с. Или вы будете спорить с тем, что 1с — тьюринг полный ЯП?
Извините, но Вы представляете что такое аптека? В чем заключается работа аптеки? Я занимаюсь аптеками 17 лет уже, насмотрелся много чего. 1С-Аптеку тоже видел. Далеко не айс.
Говорить что "программа выполняет то что требует государство"… Я не написал что 1С-ка не выполняет своих задач — очень даже выполняет. Проблема не в ней, а в тех требованиях которые выдвигаются со стороны государства. Я считаю больше половины этих требований попросту маразматичными. И думаю что не я один — в России бухгалтера это "боги"… Только зачем усложнять систему? Людям работать надо, а не бумажки считать.
Оправдание системы которую строит государство имеет мало общего с настоящим трудом программиста. Чем занимается большинство 1С-ников? Продажей и обновлениями. Когда надо сделать какие-то доработки — о ужас, они базовых элементов не знают.
Сразу скажу — я не говорю что все 1С-ники такие. Упаси бог! У меня есть хорошие знакомые которые делают все что угодно со всеми 1С-ками… Только попробуй их себе заполучить — времени у них нет. А остальные развращены 50% маржи с продажи. Проще продать и получить от 10-ки за 2 напечатанных бумажки, потом брать по 1,5 деревянных штуки за час и жить припеваючи (московские цены еще выше).
Да, на 1С можно написать что-то более-менее нормальное. Не спорю. Но ее задача это в основном продвигать бухгалтерию — на этом зарабатывается больше всего (насколько я понимаю).
P.S. Оговорюсь сразу — могу ошибаться в плане последних наработок 1С. Вполне возможно что там что-то есть толковое. но ориентация 1С идет на местный российский рынок. А это определяет уровень. по мне так — не самый высокий. Но другое мнение "приветствуется
"
Извините, но Вы представляете что такое аптека? В чем заключается работа аптеки? Я занимаюсь аптеками 17 лет уже, насмотрелся много чего. 1С-Аптеку тоже видел. Далеко не айс.
Выше вы уже написали отличия аптеки от обычной торговой точки. Что удивило:
1) Скромный ассортимент. У вас потолок 10000 — для меня это среднестатистический ларек. Ожидал увидеть что-то вроде 40000.
2) Накладные по несколько сот позиций — опять же, типично для торговли.
3) Нестандартизированный ассортимент. Видимо плохо смотрели на 1С Аптеку — на отраслевом ИТС есть справочник лекарственных средств. Импортируйте и не надо руками вбивать.
4) Вас почему-то напугали накладные поставщика. Но обычно это первое, что автоматизируется в любом торговом предприятии: автозагрузка накладных из экселя кастомного формата. Да и из коробки в той же УТшке давно есть этот функционал.
5) Аптеки на 1ске — да на каждом углу.
Проблема не в ней, а в тех требованиях которые выдвигаются со стороны государства.
Вы правда не понимаете логику государства? Ну простой пример. Есть такая геморройная штука как НДС. Вас правда удивляет требование налоговой сдавать реестр счетов фактур? Вас правда удивляет требование ввести онлайн кассы по 54 ФЗ? Для Вас сюрприз, что в ОФД будут передаваться номера ГТД по каждой проданной позиции?
Могу пояснить: государство имеет техническую возможность качественно повысить уровень проверок. И использует эту возможность для закручивания гаек. Может мне это и неприятно, но по крайней мере, я понимаю смысл требований.
Только зачем усложнять систему? Людям работать надо, а не бумажки считать.
А государству нужно с работающих людей налоги стричь. И государство решило плотно заняться этим процессом, а не пускать его на честность бизнесменов.
Чем занимается большинство 1С-ников? Продажей и обновлениями.
Рискну предположить, что большинство 1сников занимается внедрениями. Т.е. допил решения под нужды/прихоть заказчика.
Когда надо сделать какие-то доработки — о ужас, они базовых элементов не знают.
А, я понял, о чем вы. Полностью согласен. Уровень подавляющего большинства 1сников — потрясающий. Ну это плата за порог вхождения. Причем, позитивная плата, на самом деле. Говорит о том, что 1ска — легкоусвояема.
Но ее задача это в основном продвигать бухгалтерию — на этом зарабатывается больше всего (насколько я понимаю).
Задача продвигать бухгалтерию реализуется ровно потому что бухучет постоянно меняется. И мало кто хочет мониторить законодательство и отражать изменения в продуктах. А так, управленческий учет — это львиная доля задач 1с.
но ориентация 1С идет на местный российский рынок. А это определяет уровень.
Что все так зациклены на буржуйских рынках? Ну прямо таки каждый второй программист рассчитывает срулить из страны.
«Извините, но Вы представляете что такое аптека? В чем заключается работа аптеки? Я занимаюсь аптеками 17 лет уже, насмотрелся много чего. 1С-Аптеку тоже видел. Далеко не айс.»
Возможно вы сможете на базе существующих решений сделать отраслевое для аптек которое заткнет за пояс существующее решение?
Возможно вы сможете на базе существующих решений сделать отраслевое для аптек которое заткнет за пояс существующее решение?
Не скажите. Это лишь обобщенный ярлык. Шестой год веду разработки на 1С. Все описанное в статье лишь вскользь на слуху, но ни разу не вникал основательно в это все бухгалтерское. Не приходилось пока решать задачи с этим связанные. При этом программист во мне живее всех живых, в процессе работы 1С-ником освоил C# (в начале карьеры писал на Delphi), есть рабочие проекты в которых С# и 1С очень выигрышно заинтегрированы.
Разработки на 1С так же тесно переплетены с прямыми запросами к MS-SQL, и тут не обойтись без нормализации, оптимизации как способа хранения данных так и способа записи\чтения данных (Очень объемная база, и большой поток данных. И в нашем случае резать базу — нельзя! Она с 2002го года накапливается). Словом то что делаю я — описанный Вами 1С-ник делать не будет. Но и в тоже время я как 1С-ник многого не знаю из того что делает описанный Вами 1С-ник.
Думаю все дело в том — каким конкретно 1С-ником становится тот или иной конкретный человек, и какой род деятельности он выбирает. Ходить и «накатывать» типовые обновления и изобретать велосипеды (после которых ещё и база начинает жутко висеть) по заказу бухов, не разобравшись с сутью задачи, либо входить в реальный, крутые проекты, где много интересной и сложной работы и становиться реальным программистом, пишущим как на русском так и на английском.
Разработки на 1С так же тесно переплетены с прямыми запросами к MS-SQL, и тут не обойтись без нормализации, оптимизации как способа хранения данных так и способа записи\чтения данных (Очень объемная база, и большой поток данных. И в нашем случае резать базу — нельзя! Она с 2002го года накапливается). Словом то что делаю я — описанный Вами 1С-ник делать не будет. Но и в тоже время я как 1С-ник многого не знаю из того что делает описанный Вами 1С-ник.
Думаю все дело в том — каким конкретно 1С-ником становится тот или иной конкретный человек, и какой род деятельности он выбирает. Ходить и «накатывать» типовые обновления и изобретать велосипеды (после которых ещё и база начинает жутко висеть) по заказу бухов, не разобравшись с сутью задачи, либо входить в реальный, крутые проекты, где много интересной и сложной работы и становиться реальным программистом, пишущим как на русском так и на английском.
А автору статьи — спасибо за столь детальный разбор терминологии, возможно когда-то пригодиться. Читается легко и увлекательно.
Разработки на 1С так же тесно переплетены с прямыми запросами к MS-SQL,Подскажите, а что, в 1С можно делать прямые запросы к базе данных? Прям на T-SQL? Насколько я знаю, там нечитабельная структура данных. Кроме как встроенным языком до них трудно добраться.
В общем случае так и есть. Точнее — не всегда выделка шкурки стоит. Но в некоторых специфических задачах оно того стоит.
В платформе имеется функция которая возвращает физическое наименование таблиц, полей и даже индексов — для всех или для указанных объектов дерева конфигурации.
В моем случае — я гоняю очень большие объемы данных по регистрам сведений.
В одном из случаев запись данных в 3 регистра сведений, которые между собой переплетены GUID'ами, через T-SQL запросы происходит на 30% быстрее чем механизмами 1С. Когда общее время работы записи достигает 3-4 часов — это ощутимая разница. А далее еще интереснее задача. Когда данные в определенном разрезе необходимо перезаписать. Надо сначала удалить то что уже есть. Но удалить только то что следует, условий много накладывается. Регистры не зависимые. Накладывать отборы на менеджеры записей — долго и ресурсозатратно. А вот скрипт T-SQL отрабатывает за секунды времени.
Одна из моих первых задач, подобного рода, позволила ускорить обработку данных в регистре сведений с 3х часов до 4х минут, тоже благодаря T-SQL.
Но другой момент что с этим надо быть очень аккуратно. А главное не писать в коде имена таблиц и полей для SQL. А каждый раз получать их динамически, на тот случай если после очередного обновления релиза платформы, сменится какая-нибудь система именования объектов. Или что-то ещё. В общем везде двойные проверки корректности — обязывают быть) Что бы не испортить базу)
Сама 1С все эти манипуляции с данными не очень одобряет. Но в некоторых ситуациях — без этого реально сложновато.
В платформе имеется функция которая возвращает физическое наименование таблиц, полей и даже индексов — для всех или для указанных объектов дерева конфигурации.
В моем случае — я гоняю очень большие объемы данных по регистрам сведений.
В одном из случаев запись данных в 3 регистра сведений, которые между собой переплетены GUID'ами, через T-SQL запросы происходит на 30% быстрее чем механизмами 1С. Когда общее время работы записи достигает 3-4 часов — это ощутимая разница. А далее еще интереснее задача. Когда данные в определенном разрезе необходимо перезаписать. Надо сначала удалить то что уже есть. Но удалить только то что следует, условий много накладывается. Регистры не зависимые. Накладывать отборы на менеджеры записей — долго и ресурсозатратно. А вот скрипт T-SQL отрабатывает за секунды времени.
Одна из моих первых задач, подобного рода, позволила ускорить обработку данных в регистре сведений с 3х часов до 4х минут, тоже благодаря T-SQL.
Но другой момент что с этим надо быть очень аккуратно. А главное не писать в коде имена таблиц и полей для SQL. А каждый раз получать их динамически, на тот случай если после очередного обновления релиза платформы, сменится какая-нибудь система именования объектов. Или что-то ещё. В общем везде двойные проверки корректности — обязывают быть) Что бы не испортить базу)
Сама 1С все эти манипуляции с данными не очень одобряет. Но в некоторых ситуациях — без этого реально сложновато.
Спасибо за развернутый ответ. Стало понятно.
Вам не кажется, что в этом случае, вы решаете проблемы, созданные искусственно? Ведь разработчики платформы могли бы создать БД с классическими названиями таблиц: documents, journal, agents и т.д. Могли бы не менять эти названия в обновлениях. С какой целью вообще разработчики так усложняют структуру БД и работу программистов?
Вам не кажется, что в этом случае, вы решаете проблемы, созданные искусственно? Ведь разработчики платформы могли бы создать БД с классическими названиями таблиц: documents, journal, agents и т.д. Могли бы не менять эти названия в обновлениях. С какой целью вообще разработчики так усложняют структуру БД и работу программистов?
Благо на текущий момент не сталкивался с таким явным изменением структуры тех таблиц с которыми чаще приходится работать через СУБД напрямую. Но о таких рисках меня предупреждали, поэтому учитываю. А вот для примера GUID представленный в 1С и как он пишется в СУБД — можете поискать. Есть картинки где схематично изображено какой бит GUID'а куда необходимо сместить что бы получилось представление вида 1С. Или напротив. Очень интересная схема. Объяснения я не нашел — почему именно так?
А так по сложностям, я думаю что глобально и технически, разработчикам платформы и механизмы удаления и записи через запросы — не сложно было бы реализовать. Не говоря уже о более человеческом представлении данных на уровне СУБД.
Думаю что все так реализовано в первую очередь для защиты данных. Для максимальной защиты от вмешательства в базу данных из вне. Так как любое действие с данными на уровне платформы фиксируется в журнале изменений (худо бедно (если не использовать сторонние разработки), но фиксируется) и затем всегда можно сказать кто виновато в том что тот или иной документ или проводка были изменены\удалены и прочее. А вот если делать это напрямую через СУБД то уже никаких логов в явном виде — не останется. Крайних потом не найти. Думаю поэтому все обстоит именно так. Плюс элементарно защита от не правильных действий. Ну мало ли кому придет в голову изменить структуру на уровне СУБД, а платформа потом порушит базу из-за такой исключительной ситуации. А так официально запретили лазить куда не следует, и ответственность с себя сняли.
Плюс к тому — необходимость лесть на уровень СУБД это удел как правило очень крупных проектов. Возможно 1С изначально не рассчитывали на подобное использование их платформы. Либо не оценивали таких масштабов. Постепенно совершенствуются. Оптимизируют. Будем смотреть и верить в лучшее. Может в будущем мои оптимизации через СУБД потеряют весь смысл.
А так по сложностям, я думаю что глобально и технически, разработчикам платформы и механизмы удаления и записи через запросы — не сложно было бы реализовать. Не говоря уже о более человеческом представлении данных на уровне СУБД.
Думаю что все так реализовано в первую очередь для защиты данных. Для максимальной защиты от вмешательства в базу данных из вне. Так как любое действие с данными на уровне платформы фиксируется в журнале изменений (худо бедно (если не использовать сторонние разработки), но фиксируется) и затем всегда можно сказать кто виновато в том что тот или иной документ или проводка были изменены\удалены и прочее. А вот если делать это напрямую через СУБД то уже никаких логов в явном виде — не останется. Крайних потом не найти. Думаю поэтому все обстоит именно так. Плюс элементарно защита от не правильных действий. Ну мало ли кому придет в голову изменить структуру на уровне СУБД, а платформа потом порушит базу из-за такой исключительной ситуации. А так официально запретили лазить куда не следует, и ответственность с себя сняли.
Плюс к тому — необходимость лесть на уровень СУБД это удел как правило очень крупных проектов. Возможно 1С изначально не рассчитывали на подобное использование их платформы. Либо не оценивали таких масштабов. Постепенно совершенствуются. Оптимизируют. Будем смотреть и верить в лучшее. Может в будущем мои оптимизации через СУБД потеряют весь смысл.
Где остановиться на «могли бы не менять»? Наверняка, не просто так меняют, а для реализации новых требований. Спасибо надо говорить, что есть штатный инструмент получения данных маппинга модели на базу, который позволяет обновлять модули, напрямую работающие с базой, значительно реже чем меняется схема базы.
Потому что платформа 1С это ORM система, ее задача как раз абстракция над СУБД.
Сегодня ваше решение работает в файловом варианте (вообще без таблиц, самописная СУБД) завтра ее подняли на DB2, после завтра решили перейти на postgresql), при этом ваше решение может работать на Win, Linux,Android, iOS, WEB.
Платформа по возможности старается дать вам максимальный уровень абстракции.
Не одна система с высоким уровнем абстракции не позволяет менять что то минуя все уровни.
Сегодня ваше решение работает в файловом варианте (вообще без таблиц, самописная СУБД) завтра ее подняли на DB2, после завтра решили перейти на postgresql), при этом ваше решение может работать на Win, Linux,Android, iOS, WEB.
Платформа по возможности старается дать вам максимальный уровень абстракции.
Не одна система с высоким уровнем абстракции не позволяет менять что то минуя все уровни.
Ведь разработчики платформы могли бы создать БД с классическими названиями таблиц: documents, journal, agents и т.д. Могли бы не менять эти названия в обновлениях
Дело тут в уровне абстракций. Я сам создавал платформу, чем то напоминающую платформу 1С, но структурно более правильно устроенную, на уровне ядра, и полностью конфиугрируемую в вебе (можно здесь почитать если интересно https://erp-platforma.com/s?tex=1).
Надо разделять пользовательский и системный уровни. И для удобства и для безопасности. На пользовательском — читаемые имена. Но если пользователь накосячит, физически это не должно уйти в БД, а должно на уровне компилирования дать отбой.
А имена на системном это уже не важно, удобнее при компиляции и интерпитации с числовыми значениями работать.
И кстати не только в этом удобство. Если есть четкая стуктура хранения конфигурации, можно делать удивительные вещи. Снапшоты элементов конфигурации, версии, умные обновления (копирование и встраивание в другие конфигурации элементов новых конфигураций), расширение функций БД: например можно sql запросом выводить изображения (тип данных такой сделали для удобства), штатно одной фнунцией делать контрольные суммы строк + блокчейн (со связью с хешами других строк), автоматизацию работы (CRUD).
Все это позволяет делать разделение на уровни абстракций.
Например вывод изображений в sql запросе физически хранится как число — идентификатор записи в таблице с blob изображений, а интерпретатор это уже тосует и подсовывает сам на пользовательский уровень. И для пользователя это выглядит как работа с изображениями в sql запросе.
Но если залезть при этом у саму БД — вы увидите таблицы, триггера и процедуры в виде наборов чисел.
А имена на системном это уже не важно, удобнее при компиляции и интерпитации с числовыми значениями работать.
А вы что, во время разработки своей платформы в базу данных глазами не заглядывали? Для меня это ключевой фактор на самом деле — софтине в общем-то всё равно, какие там идентификаторы, читабельные, или нет. А вот для человека, который что-то расследует на уровне базы данных, разница огромная.
Заглядывал. На то это и разработка. Когда разрабатываешь ядро полюбе надо копаться.
Более того, было 3 версии ядра. Первая была на именах кстати. И 2 первые были выброшены на помойку из-за изначально неправильно выбранного пути, когда упирались в технически непроходимые вещи и понимали что надо было не так делать. Но на набитых шишках была сделана 3 версия, быстрая, стабильная и расширяемая. В общем покапаться дай боже пришлось.
Но разработка ядра не относится к работе программистов на платформе.
Для этого прямо в веб интерфейсе можно писать процедуры и триггера с нормальными именами, которые будут компилироваться в БД. Нет необходимость лезть в саму базу.
Но SQL надо понимать. Без этого никуда.
Более того, было 3 версии ядра. Первая была на именах кстати. И 2 первые были выброшены на помойку из-за изначально неправильно выбранного пути, когда упирались в технически непроходимые вещи и понимали что надо было не так делать. Но на набитых шишках была сделана 3 версия, быстрая, стабильная и расширяемая. В общем покапаться дай боже пришлось.
Но разработка ядра не относится к работе программистов на платформе.
Для этого прямо в веб интерфейсе можно писать процедуры и триггера с нормальными именами, которые будут компилироваться в БД. Нет необходимость лезть в саму базу.
Но SQL надо понимать. Без этого никуда.
В целом кстати и на уровне БД не так все сложно. Есть конфигурационные таблицы где можно по пользовательскому имени найти идентфикатор, с которым это в БД, и лезть уже предметно.
В 1С наверное тоже есть нечто подобное.
В 1С наверное тоже есть нечто подобное.
В 1С так можно, но все равно, делать там что-то в обход ORM жутко неудобно. Хотя бывает и продуктивно, например, массовую загрузку данных между 1С и MS Dynamics NAV я как-то реализовывал через прямую запись в БД. В результате несколько часов сократились до одной минуты. Но до этого пришлось долго и мучительно разбирать 1Сные метаданные.
Когда ядро реализовывалось, закладывалось как раз то, что можно напрямую из интерфейса создать процедуру, которая будет скомпилирована в БД и ее дергать. Т.е. чтобы такие операции выполнялись на уровне БД. В общем ядро дергает уже скомпилированный в БД элемент, передавая ему только нужные параметры, и получает от него готовый результат. Поэтому это будет быстро и при конфигурировании из интерфейса. Да и в целом на таком принципе все работает, поэтому работает быстро. В этом ключевое отличие от ядра 1С.
«Сама 1С все эти манипуляции с данными не очень одобряет. Но в некоторых ситуациях — без этого реально сложновато.»
Потому что когда вы меняете данные минуя ORM слой вы игнорируете:
Роли;
Подписки на события;
Обработчики событий объектов;
Регистрацию изменений для обменов;
Проверку ссылочной целостности:
Не выполняется журналирование изменений;
Не работают управляемые блокировки.
Появляется зависимость от конкретной СУБД (файловый вариант, DB2, postgresql отпадают)
И это только верхушка, если копнуть глубже можно список побольше набрать.
Для себя в своем карманном проекте вы можете это делать на свой страх и риск. Но сертифицировать подобный продукт как типовой которым будут пользоваться дестяки тысяч разработчиков по всей стране 1С не будет.
Не удивительно что настоящие программисты (Разработчики платформы 1С) против такого варварского отношения к системе. Такие же ограничения есть и для любой ORM.
Если вы хотите использовать запросы на TSQL то и логику всю нужно писать на SQL (Тригеры, ограничения(Constraints), ролевую модель SQL).
Потому что когда вы меняете данные минуя ORM слой вы игнорируете:
Роли;
Подписки на события;
Обработчики событий объектов;
Регистрацию изменений для обменов;
Проверку ссылочной целостности:
Не выполняется журналирование изменений;
Не работают управляемые блокировки.
Появляется зависимость от конкретной СУБД (файловый вариант, DB2, postgresql отпадают)
И это только верхушка, если копнуть глубже можно список побольше набрать.
Для себя в своем карманном проекте вы можете это делать на свой страх и риск. Но сертифицировать подобный продукт как типовой которым будут пользоваться дестяки тысяч разработчиков по всей стране 1С не будет.
Не удивительно что настоящие программисты (Разработчики платформы 1С) против такого варварского отношения к системе. Такие же ограничения есть и для любой ORM.
Если вы хотите использовать запросы на TSQL то и логику всю нужно писать на SQL (Тригеры, ограничения(Constraints), ролевую модель SQL).
Разве автор писал что-нибудь про 1С?
Автор занимается украинскими программами.
Но бухгалтерская терминология примерно одинакова для любых бухгалтерских программ. Они же бухгалтерские. Другое дело, что иногда используется как попало. Вперемешку термины из различных отраслей и даже из различных стран.
Кстати, автоматизацией аптек мы тоже занимались. Все довольны. Базы не падают. Никто их не восстанавливает по пол-дня. Никаких пересменок по два часа, чтобы скачать данные в центральный офис.
Украинский аптечный холдинг: 200 аптек, основные БД: 21 млн. и 104 млн. проводок, всего около 10 баз данных, таблица партий около 7 млн записей. Все крутится круглосуточно и непрерывно.
Автор занимается украинскими программами.
Но бухгалтерская терминология примерно одинакова для любых бухгалтерских программ. Они же бухгалтерские. Другое дело, что иногда используется как попало. Вперемешку термины из различных отраслей и даже из различных стран.
Кстати, автоматизацией аптек мы тоже занимались. Все довольны. Базы не падают. Никто их не восстанавливает по пол-дня. Никаких пересменок по два часа, чтобы скачать данные в центральный офис.
Украинский аптечный холдинг: 200 аптек, основные БД: 21 млн. и 104 млн. проводок, всего около 10 баз данных, таблица партий около 7 млн записей. Все крутится круглосуточно и непрерывно.
«Чисто подход 1С-ника» — поржал, чо (с учетом бэкграунда аффтыря)
Вообще 1С это платформа включающая в себя СУБД, Среду разработки, Язык программирования.
Вы же не пишите что Android Studio не подходит аптекам?
На платформе 1С разработано множество решений.
Как типовых (1С: Управление производственным предприятием, 1С: Бухгалтерия, 1С: Зарплата и Управление
Персоналом)
Так и отраслевых solutions.1c.ru в.т.ч. и специально для аптек: solutions.1c.ru/catalog/drugstore/features
«От программистов там мало что осталось.»
Не меньше чем у типового WEB разработчика который клепает интернет магазины и порталы со стартапами.
Вы же не пишите что Android Studio не подходит аптекам?
На платформе 1С разработано множество решений.
Как типовых (1С: Управление производственным предприятием, 1С: Бухгалтерия, 1С: Зарплата и Управление
Персоналом)
Так и отраслевых solutions.1c.ru в.т.ч. и специально для аптек: solutions.1c.ru/catalog/drugstore/features
«От программистов там мало что осталось.»
Не меньше чем у типового WEB разработчика который клепает интернет магазины и порталы со стартапами.
Но бухгалтерская терминология примерно одинакова для любых бухгалтерских программ.
Насчет терминологии, конкретно к автору — я бы поспорил. как меня учили «динозавры» — бух.учета сальдо это просто РАЗНИЦА между приходом и расходом. Если сальдо положительное(приход больше расхода) то оно дебетовое, если отрицательное (приход меньше расхода) то кредитовое
Забываете про начальное сальдо.
Как в анекдоте. Буратине дали три яблока. Два он съел. Сколько яблок осталось у Буратины? Думаете одно? Ничего подобного. Никто же не знает сколько у него уже было яблок до этого. Мораль – обнуляйте переменные!
А у нас мораль, учитывайте начальное сальдо :) только оборотов недостаточно. Не о чем спорить
Как в анекдоте. Буратине дали три яблока. Два он съел. Сколько яблок осталось у Буратины? Думаете одно? Ничего подобного. Никто же не знает сколько у него уже было яблок до этого. Мораль – обнуляйте переменные!
А у нас мораль, учитывайте начальное сальдо :) только оборотов недостаточно. Не о чем спорить
А у нас мораль, учитывайте начальное сальдо :) только оборотов недостаточно. Не о чем спорить
Так кто же спорит?
Вот автор написал что «главная книга» понятие устаревшее. Может быть и так сейчас, но в 90-е мы писали свои программы было понятие «начальное сальдо» Если дебетовое то значение с плюсом, если кредитовое то с минусом
P.S есть хохма про бух.учет «сальдо-бульдо» Так вот понятия «бульдо» в бухучете НЕТ. Его придумали просто в рифму типа «шашлык-машлык»
Насчет терминологии, конкретно к автору — я бы поспорил.Как бы в ответ на эту фразу :)
Ну, правильно написал. Просто при бумажном учёте первичка собирается в регистры, из них — в другой регистр «главную книгу», а уже оттуда можно в отчётность.
Сейчас при автоматизации учёта мы формируем записи, а всё остальное обобщается как угодно, собирается в любые выходные формы. Естественно, что промежуточных регистров, как инструмента для обобщения данных, теперь нет в принципе. Они сами теперь всего лишь выходные формы.
А про рифму, ну глупость какая-то. Ну срифмовали бы сальдо — фигальдо. И то красивее бы было.
А про рифму, ну глупость какая-то. Ну срифмовали бы сальдо — фигальдо. И то красивее бы было.
Эта рифма была еще со времен бумажного бухучета
Да в курсе, застал.
От времени результат жизнедеятельности мамонта не стал вкусняшкой. Разве что окаменел :)
От времени результат жизнедеятельности мамонта не стал вкусняшкой. Разве что окаменел :)
Да в курсе, застал.
Не похоже Судя во вот этому
Сейчас при автоматизации учёта мы формируем записи, а всё остальное обобщается как угодно, собирается в любые выходные формы. Естественно, что промежуточных регистров, как инструмента для обобщения данных, теперь нет в принципе. Они сами теперь всего лишь выходные формы.
Потому что это типично для 1С — писать запросы а из их результатов формировать отчетность. Посмотрел бы я сколько подобные вещи обрабатывались (формировались) на 386 или даже 486 машинах
От времени результат жизнедеятельности мамонта не стал вкусняшкой. Разве что окаменел :)
Советую погулить стоимость бивней мамонтов
Чё не похоже? Я говорю про времена бумажного учёта. Что не так, при чём тут 386?
Когда появились, нормально всё формировалось. И бюджетый тоже, кстати. И под досом.
Мамонты не срут бивнями, если вы не поняли, о чём я. Хоть загуглись.
Когда появились, нормально всё формировалось. И бюджетый тоже, кстати. И под досом.
Мамонты не срут бивнями, если вы не поняли, о чём я. Хоть загуглись.
Я говорю про времена бумажного учёта. Что не так, при чём тут 386?
Потому что во время 386 машин бухучет не сильно отличался от классического бумажного
Естественно, что промежуточных регистров, как инструмента для обобщения данных, теперь нет в принципе. Они сами теперь всего лишь выходные формы.
Вот это как раз ПРОТИВОестественно так как человеческую ошибку искать В РАЗЫ ТРУДНЕЕ
Сейчас при автоматизации учёта мы формируем записи, а всё остальное обобщается как угодно, собирается в любые выходные формы.
Этот подход как раз рассчитан на пожирания аппаратных ресурсов вместо того чтобы оптимизировать рассчеты
Я что-то не пойму, вообще к чему это всё?
Вам видится что бумажный учёт, то же самое, что и автоматизированный. Ваше право так считать. Я тут причём?
Нравятся вам рифмы. Прекрасно. Не ко мне.
С наилучшими пожеланиями.
Вам видится что бумажный учёт, то же самое, что и автоматизированный. Ваше право так считать. Я тут причём?
Нравятся вам рифмы. Прекрасно. Не ко мне.
С наилучшими пожеланиями.
Вам видится что бумажный учёт, то же самое, что и автоматизированный.
Он ДОЛЖЕН БЫТЬ таким же самым. Иначе это не учет а фикция.
Простой пример
Покупатель ВОЗВРАЩАЕТ товар по гарантии. После товар чиниться в гарантийной мастерской и снова выставляется на продажу. 1С просто сходит с ума в таких случаях — прибыль может быть просто огромной или наоборот уйти в минус — все зависит от клолебания цен
Не должен он быть таким же. Очень многое в бумажном учёте ориентировано на то, чтобы для отчётов постоянно не перерывать первичку, с одной стороны, а, с другой, чтобы вовремя заметить ошибки при переносе данных из первички в журналы, а из журналов в отчёты. Сейчас вполне достаточно при небольших объёмах первички получать информацию из неё прямыми запросами, а при больших использовать технические средства повышения производительности выборок.
с другой, чтобы вовремя заметить ошибки при переносе данных из первички в журналы
А с ошибками как быть? Человеку свойственно ошибаться — это еще с Древнем Риме говорили «Errāre humānum est»
Приходилось слышать?
Я в своих самоделках не столько косяки программы вычищал, сколько ошибки бухгалтеров. Да и с 1С сталкивался с тем что «булгахтеры» не на тот счет разнесли а потом у них например НДС не бился
Как бы не хаяли бюрократов из СССР а отчетность бухгалтерская создавала большие сложности для желающих украсть. Хотя… те кто меня учил отчетности говорили — «это в математике 5 на 2 без остатка не делиться а в бухгалтерии запросто»
Ну так автоматизация минимизирует вероятность ошибок бухгалтеров и прочих. Ошибка возможна только на этапе ввода первичных документов или физической работы с товарами/деньгами. А вот проверки могут носить совершенно другой характер по сравнению с подбиванием итогов из разных журналов и сравнением их с актами инвентаризации.
Ошибка возможна только на этапе ввода первичных документов или физической работы с товарами/деньгами
Все верно. И чего только дураки не творят
А вот проверки могут носить совершенно другой характер по сравнению с подбиванием итогов из разных журналов и сравнением их с актами инвентаризации.
Например? Может у меня и осталось такое же мышление как у тех кто меня бухгалтерии учил но ничего лучшего пока не придумали.
«Посмотрел бы я сколько подобные вещи обрабатывались (формировались) на 386 или даже 486 машинах»
Посмотрели бы вы как на 386 или даже 486 машинах работали бы современные технологии: (Java, JabaScript, C#)
Почему камень только в сторону 1С?
Посмотрели бы вы как на 386 или даже 486 машинах работали бы современные технологии: (Java, JabaScript, C#)
Почему камень только в сторону 1С?
Почему камень только в сторону 1С?
Потому что подобного подхода я больше нигде кроме 1С не встречал. Соберем сырые данные в кучу а после запросами сделаем выборку и сформируем отчет. Если и есть в каких программах кроме 1С подобное то я их не знаю. Во всяком случае на FoxPro мы так не делали. там проще связей между базами понаделать (только за индексами внимательно следить) И в отчет выводить по условию. Можно и запросами(Query) как в 1С но не все же подряд
А статью лучше назвать как-нибудь «бухучет для сопровожденцев 1С». От программистов там мало что осталось.
Согласен. Сам имел фирму в 90-е писали различные бухгалтерские программы на СУБД FoxPro. Но… не выдержали конкуренции с 1С
Самое забавное что нынешние «бухгалтера» (в кавычки взял не зря) ВООБЩЕ не понимают сути бух.учета. На различных курсах их учат что нажать в 1С. Мне повезло — еще в 90-е свел знакомство с несколькими БУХГАЛТЕРАМИ которые и без компьютера с карандашом и тетрадкой сведут баланс… Но то «динозавры»
А вот статья запоздала лет на 10-20… Но это ИМХО — как раз тогда мне не хватало понимания ЧТО НУЖНО СДЕЛАТЬ. То есть взять цифру из это базы сложить(отнять) от другой а результат поместить в эту базу. Вот как раз тогда и помогли эти «динозавры»-бухгалтера старой школы
спасибо, познавательно
Вообще, управленческий учет как раз намного важнее бухгалтерского. Бухучет — это регламентированный учет, который действительно оперирует суммами, и в общем-то представляет лишь регистрацию определенных фактов в деятельности предприятия. Информацию для анализа текущего состояния предприятия и для принятия решений по его, собственно, управлению, предоставляет именно управленческий учет. Бухгалтерский учет скажет, что у вас на счету «Товары» лежат такие-то товары на сумму 100500 денег. Управленческий скажет, какие партии, кто из них неликвиды, на каких складах в каких городах лежат, каких товаров, которые числятся в бухучете, на самом деле нет (т.к. были проданы мимо кассы ;-) и т.д.
Вы только что разложили то, что в универе преподают целый семестр.
Не преувеличивайте :) Пару вводных лекций, и то с неточностями и в вольном стиле. Курс бухучёта в первую очередь состоит из практик, что и как учитывать. Понять, что такое проводка — пять минут. А вот запомнить, какие комбинации проводок для каких хозяйственных операций делать — это не один месяц.
Совершенно согласна. Это всё равно что почитать мануал по фреймворку — всё понятно, никаких вопросов нет, с примерами в книжке тоже всё ясно. А начинаешь писать реальный проект… И тут сразу же выясняется, что ничегошеньки ты ещё не умеешь и даже не понимаешь. Как ребёнок, который вроде все буквы выучил, а читать всё равно не умеет.
Пока не стану рассказывать о Зарплате, поскольку, если вы собираетесь начислять зарплату, вы наверняка знаете, что делаете.
А вот зря. Нагрузка, которую несёт работодатель, не ограничивается же только выплатами зарплаты работнику — почему-то до сих пор это не для всех очевидно и люди с удивлением узнают сколько отчислений за них приходится делать работодателю. Было бы интересно узнать актуальное состояние. Если будет желание добавить в статью несколько абзацев — только приветствую.
люди с удивлением узнают сколько отчислений за них приходится делать работодателю.
Надо выдавать всем на руки зарплату без вычета налога и взносов на пенсионку, медстраховку и прочее. А в конце года гражданин должен будет приходить в банк и сам платить эдак тысяч 600 рублей (при чистой зарплате 100 тысяч в месяц). И тут у него появится масса вопросов и про Димона, и про дворцы, и почему медицина за его деньги такая убогая. Это позволит ему по-моему обдумать вопрос Крыма (куда тупо забрали накопительные взносы), вопрос Сирии и много чего ещё в нашей стране. И именно поэтому так не сделают.
Надо подумать. Вообще-то цель была — приятное знакомство с бухгалтерскими терминами, чтобы программист/настройщик/продавец-ПО мог более-менее спокойно вести диалог с пользователем-бухгалтером. Да, пожалуй, вы правы. Можно будет расшифровать общие принципы расчета зарплаты. И спрятать под кат, на всякий случай. ))
Про активы и пассивы как то не полностью пояснили. Активы это собственное имущество. Пассивы это откуда, за счёт чего эта собственность взялась. Можно провести аналогию между законом сохранения материи (энергии) и бухгалтерским балансом, имущество ниоткуда не возникает и никуда не девается.
Покажу на примере. Покупатель денег дал, количество денег у нас возросло, но увеличился и долг (пассив). Через некоторое время товар этому покупателю отдали, количество товара (имущество, актив) у нас уменьшилось, но уменьшается и наш долг (пассив). Получается 2 записи (проводки) и всегда равновесие (баланс) сохраняется. Нарушение равновесия, это признак проблем.
Надо бы продолжение написать, где пояснить разницу между деньгами, доходом, и прибылью с разбором примеров.
Или проще: баланс всегда равен нулю, если не равен — это не баланс.
Бедненько живёте, раз баланс у вас всегда равен нулю.
Вообще-то, если говорить, что баланс чему-то равен, надо сказать что Баланс = Актив = Пассив. И если у вас хоть копейка в кассе, то он априори нулю не может быть равным.
Взгляните на форму №1, прежде чем так «упрощать»
Вообще-то, если говорить, что баланс чему-то равен, надо сказать что Баланс = Актив = Пассив. И если у вас хоть копейка в кассе, то он априори нулю не может быть равным.
Взгляните на форму №1, прежде чем так «упрощать»
Если у меня копейка в кассе — то у меня оборотный актив «денежные средства и их эквиваленты» в размере копейки, уравновешенный либо соответствующими обязательствами перед поставщиками, либо нераспределенной прибылью, либо капиталом.
Баланс = отчет, включающий в себя части про активы и пассивы, при этом активы = пассивы, баланс = сумма активов и пассивов = 0.
В форме №1 есть строчки «баланс» на месте «итого», это не «баланс» в понимании, скажем, МСФО или даже российского бухучета. Вообще, чтобы придумать в одном документе 2 строчки с одинаковым (и совпадающим с заголовком, но не совпадающим с сутью) названием, но разными кодами — надо быть российским законодателем.
Баланс = отчет, включающий в себя части про активы и пассивы, при этом активы = пассивы, баланс = сумма активов и пассивов = 0.
В форме №1 есть строчки «баланс» на месте «итого», это не «баланс» в понимании, скажем, МСФО или даже российского бухучета. Вообще, чтобы придумать в одном документе 2 строчки с одинаковым (и совпадающим с заголовком, но не совпадающим с сутью) названием, но разными кодами — надо быть российским законодателем.
А если фирме что‐то подарили, то активы увеличились, а долги нет. Что делать?
а долги записываются на отдельный счет «подарки фирме».
Безвозмездный подарок = чистая прибыль, соответственно, в источниках (в пассиве) увеличивается прибыль, а в активе — собственно подарок.
Баланс всегда соблюдается ибо двойная запись.
Баланс всегда соблюдается ибо двойная запись.
в пассивах пишем прибыль. дальше ее либо в уставняк, либо в ОС, либо выводим.
По пассиву возникают прибыль обязательства по уплате налогов, по активу на соответствующих счетах отражается собственно подаренное имущество ))
Не могу рекомендовать это как справочник :) Лучше смотрите википедию. Тут приведены упрощённые определения, верные в некоторых случаях, но не во всех.
Например, сторно — это вообще любая отменяющая проводка, не только для возврата товара используется.
Определения «дебет это приход, кредит это расход» верны только для случая, когда дебетуется активный счёт, а кредитуется пассивный.
Определение «301 это счёт кассы» меня надолго ввело в ступор. До тех пор, пока не увидел гривны :) В таких случаях надо бы указывать, какой план счетов используется.
Разделение на аналитический и синтетический учёт совсем не устарело, а активно используется: аналитический нужен для работы предприятия, но отчёты для госорганов формируются обычно в терминах синтетического учёта.
Например, сторно — это вообще любая отменяющая проводка, не только для возврата товара используется.
Определения «дебет это приход, кредит это расход» верны только для случая, когда дебетуется активный счёт, а кредитуется пассивный.
Определение «301 это счёт кассы» меня надолго ввело в ступор. До тех пор, пока не увидел гривны :) В таких случаях надо бы указывать, какой план счетов используется.
Разделение на аналитический и синтетический учёт совсем не устарело, а активно используется: аналитический нужен для работы предприятия, но отчёты для госорганов формируются обычно в терминах синтетического учёта.
Согласен, сторно — это исключительно исправляющая проводка и я бы сказал она не используется для возврата чего-либо она используется только для исправления ошибки в проводке. За частую бухгалтеры реально не понимают в чем разница и лепят как попало. Для возврата товара, денег и т.д используется обратная проводка.
Вики
Сторнировочная проводка
в бухгалтерском учёте — бухгалтерская проводка, предназначенная, как правило, для исправления ранее ошибочно произведённой записи. Обычно применяется т. н. отрицательное сторно, при котором для исправления ошибочной проводки делается дополнительная проводка, составленная на сумму ошибочной проводки, но с отрицательным знаком. Чтобы выделить отрицательные числа, их обычно пишут красными чернилами, поэтому отрицательное сторно и метод исправления ошибок с помощью сторно иногда называют «красное сторно». Метод красного сторно был разработан российским бухгалтером-практиком А. А. Беретти в 1889 году.
в бухгалтерском учёте — бухгалтерская проводка, предназначенная, как правило, для исправления ранее ошибочно произведённой записи. Обычно применяется т. н. отрицательное сторно, при котором для исправления ошибочной проводки делается дополнительная проводка, составленная на сумму ошибочной проводки, но с отрицательным знаком. Чтобы выделить отрицательные числа, их обычно пишут красными чернилами, поэтому отрицательное сторно и метод исправления ошибок с помощью сторно иногда называют «красное сторно». Метод красного сторно был разработан российским бухгалтером-практиком А. А. Беретти в 1889 году.
Он весь был придуман для того, чтобы вести учет на бумаге.
Причем еще в XVI веке. Так что да, пора бы апгрейд провести.
Слово счет – перегруженное смыслами слово. Не пугайтесь, это нормально.
Программистов перегрузкой
Тем и отличаются операторы участков (ака бухгалтеры) от настоящих бухгалтеров, что они знают не только те 80%, но и оставшиеся 20%, даже если брать только их участок.
Казалось бы — вот у нас табель учета рабочего времени (а учет рабочего времени может быть как минимум двух видов — вытесняющий и заполняющий), вот у нас начисление зарплаты, вот у нас расчет налогов и удержаний.
А теперь погнали — отпуск (и больничные) по средней. Далее интереснее — если средней еще нет? Приняли сотрудника, проработал день, ушел на больничный? А что там методичка? Молчит. Нет в ней такого случая. Зарплата у бюджетников и им подобных имеет свойство "индексироваться", и редко где индексации проходят без поседевших бухгалтеров и не потраченных бюджетов на поддержку. Особенно после того, как пойдут свежие отпуска и больничные. Далее интереснее случаи. Отправили в отпуск, начислили и выплатили отпускные и тут — тадам! — отозвали из отпуска… Можно, конечно, сделать "сторно", а деньги где? Деньги уже потратили. Вот сторно не получилось) Можно сделать перерасчет при выплате следующей зарплаты, но там тоже свои нюансы.
А переоценка валютных средств ( поступлений ТМЗ и услуг, продаж ТМЗ и услуг)? Это тоже нечто такое, чего нет в кратких методичках.
Другая тема — поступление на баланс давальческих материалов в переработку. А если в процессе участвуют не только давальческие материалы? Тут запороть учет как дважды два даже опытному бухгалтеру, а неопытному — почти что правило).
В общем, не знаю как в америках и европах, но в большинстве стран бСССР учет настолько сложный и замудренный, что иногда сам черт ногу сломит, не говоря уж об аудиторах (и да, хваленая big four не найдет и половины тех косяков, которые увидит преждевременно поседевший программист или консультант по той или иной учетной программе).
То что нужно. Жду продолжения по данной тематике.
читаю, читаю понять не могу что с нумерацией счетов не так, потом пошли проводки в гривнах и все встало на свои места )
Спасибо… запомню обязательно «Кредит-Крадет»
Становится понятно, почему мне так не везло с одинэсниками. Это не описание бухучета, а полная профанация на тему. В терминах 1с объяснить бухгалтерию нельзя. Отдельное спасибо за термины форма 1 и форма 2. Попытайтесь никогда их не применять в таком контексте. // гб с 1998 года
В терминах 1с объяснить бухгалтерию нельзя.
Согласен. Но где вы увидели «термины 1с»?
А что вас не устраивает в форме 1 и форме 2?
Приятнее слышать «форма 0710001 и 0710002»?
И почему сразу профанация? Для ликбеза вполне приличная статья. Ну, некоторые корректировки, коллеги ниже пишут об этом, но в целом годно.
Приятнее слышать «форма 0710001 и 0710002»?
И почему сразу профанация? Для ликбеза вполне приличная статья. Ну, некоторые корректировки, коллеги ниже пишут об этом, но в целом годно.
У автора:
Это немного не то, что Вы имели ввиду приводя верные коды форм.
Форма один (Ф1) – условное (тайное) название всех документов в белой бухгалтерии.
Форма два (Ф2) – условное (тайное) название всех документов черной бухгалтерии.
Это немного не то, что Вы имели ввиду приводя верные коды форм.
Пардону просим. Проглядел у автора эту дикость :)
Или это местный колорит, или придумка знакомого автору человека, короче, фантастическая ерундистика с точки зрения бухгалтеров :)
Я подумал, что вы возмутились употреблением как таковых наименований «Формы 1 и 2» по отношению к балансу и отчёту о прибылях и убытках. Но я ошибался.
Или это местный колорит, или придумка знакомого автору человека, короче, фантастическая ерундистика с точки зрения бухгалтеров :)
Я подумал, что вы возмутились употреблением как таковых наименований «Формы 1 и 2» по отношению к балансу и отчёту о прибылях и убытках. Но я ошибался.
… продавать программу выгоднее, чем программировать.
Автор по ходу профессией ошибся, надо было в торговлю.
Из своего орпыта общения с 1с никами:
1: Обслуживают 5ю точку главбуха, часто просто делают её работу по формированию отчетности или ещё что ей делать не хочется, отсюда баснословные доходы(особенно у приходящих), ибо главбух всегда на прикрытие своей 5й точки денег найдет.
2. Исходя из баснословных доходов и востребованности, достаточно богаты, на фоне др программистов, Не финансового сектора.
3. Почти все ведут неряшливо на сервере, после программиста 1с копии баз и отчетов валяются везде на всех дисках и рабочем столе гигабайтами.
4. Их неособо беспокоит что их не считают программистами потому что см п2.
5. Боготворят 1с и ненавидят одновременно, боготворят потому что п2, ненавидят потому что всё через одно место.
6. Всех мучает вопрос что курят разработчки 1с, и почему не делятся этим вешеством, хотя бы с франчами, ибо с каждым годом всё сложнее найти хоть какую то логику в их произведениях.
/ обидеть никого не хотел :)
1: Обслуживают 5ю точку главбуха, часто просто делают её работу по формированию отчетности или ещё что ей делать не хочется, отсюда баснословные доходы(особенно у приходящих), ибо главбух всегда на прикрытие своей 5й точки денег найдет.
2. Исходя из баснословных доходов и востребованности, достаточно богаты, на фоне др программистов, Не финансового сектора.
3. Почти все ведут неряшливо на сервере, после программиста 1с копии баз и отчетов валяются везде на всех дисках и рабочем столе гигабайтами.
4. Их неособо беспокоит что их не считают программистами потому что см п2.
5. Боготворят 1с и ненавидят одновременно, боготворят потому что п2, ненавидят потому что всё через одно место.
6. Всех мучает вопрос что курят разработчки 1с, и почему не делятся этим вешеством, хотя бы с франчами, ибо с каждым годом всё сложнее найти хоть какую то логику в их произведениях.
/ обидеть никого не хотел :)
Признаться, да.
Бренд 1С — это головная боль. Пользователи уверены, что все должно быть «как в 1с». Хотя интерфейс программы откровенно неудобный. Но еще хуже, когда разработчики программ считают, что должно быть «похоже на 1с». Складывается впечатление, что пользователи искалечены интерфейсом. Программисты искалечены кириллическим ЯП и кириллическим подобием SQL.
Искалеченные люди просят костылей. А мы не понимаем, зачем костыли, когда можно ходить двумя здоровыми ногами без них. Бухучет — это просто. И программы для бухучета можно делать простыми, быстрыми и удобными.
Бренд 1С — это головная боль. Пользователи уверены, что все должно быть «как в 1с». Хотя интерфейс программы откровенно неудобный. Но еще хуже, когда разработчики программ считают, что должно быть «похоже на 1с». Складывается впечатление, что пользователи искалечены интерфейсом. Программисты искалечены кириллическим ЯП и кириллическим подобием SQL.
Искалеченные люди просят костылей. А мы не понимаем, зачем костыли, когда можно ходить двумя здоровыми ногами без них. Бухучет — это просто. И программы для бухучета можно делать простыми, быстрыми и удобными.
Почему сразу «искалечены»? Привычка — вторая натура. Особенно — у юзера.
Ну, бейсик переведённый промтом — эка проблема. Если ключевые слова программирования поддаются запоминанию — пусть хоть иероглифами, хоть спецсимволами будут написаны.
Ну, бейсик переведённый промтом — эка проблема. Если ключевые слова программирования поддаются запоминанию — пусть хоть иероглифами, хоть спецсимволами будут написаны.
Складывается впечатление, что пользователи искалечены интерфейсом. Программисты искалечены кириллическим ЯП и кириллическим подобием SQL.
Змея передвигается без ног, но это не значит, что люди с их странными подпорками ущербны =)
Вообще то бух учет это 5% от всего функционала который нужен компании.
Вы же сами писали что времена изменились.
Да чисто бухгалтерию написать просто. Сложно добавить в нее документооборот, электронные подписи (согласно закону), обмен с налоговой (и поддерживать оперативно изменения в обмене), работу с банками, работу с правами доступа и ролями, расчет зарплаты, печать множество отчетов, поддержку распределнных баз в т.ч. и офлайн.
Сделать все это кастомизируемым и коробочным решением которое подойдет большинству с небольшими переделками.
Вы же сами писали что времена изменились.
Да чисто бухгалтерию написать просто. Сложно добавить в нее документооборот, электронные подписи (согласно закону), обмен с налоговой (и поддерживать оперативно изменения в обмене), работу с банками, работу с правами доступа и ролями, расчет зарплаты, печать множество отчетов, поддержку распределнных баз в т.ч. и офлайн.
Сделать все это кастомизируемым и коробочным решением которое подойдет большинству с небольшими переделками.
Читаем все что вы написали.
А теперь берем крупный завод который производит машины.
Берем команду крутых Java девелоперов с любым его фреймворком на выбор и команду недопрограммистов 1С.
Ставим задачу:
Вот вам 6 месяцев, необходимо автоматизировать бух. учет, расчет зарплаты, расчет себестоимости.
Через 6 месяцев у команды «недопрогаммистов» будет результат в виде работающего бух. учета, сдачи отчетности в налоговую, расчет зарплат, и кривой расчет себестоимости который пилить и пилить.
У крутых Java девелоперов будет порядок на серверах, DevOps и разработанная в visio «архитектура классов» которая развалится при первой же попытки реализации, а потом будет падать каждый раз когда наше гос-тво будет выдумывать новые законы и правила.
Именно поэтому по итогам работы генеральный и финансовый директора перейдут к п.2. вашего списка.
А теперь берем крупный завод который производит машины.
Берем команду крутых Java девелоперов с любым его фреймворком на выбор и команду недопрограммистов 1С.
Ставим задачу:
Вот вам 6 месяцев, необходимо автоматизировать бух. учет, расчет зарплаты, расчет себестоимости.
Через 6 месяцев у команды «недопрогаммистов» будет результат в виде работающего бух. учета, сдачи отчетности в налоговую, расчет зарплат, и кривой расчет себестоимости который пилить и пилить.
У крутых Java девелоперов будет порядок на серверах, DevOps и разработанная в visio «архитектура классов» которая развалится при первой же попытки реализации, а потом будет падать каждый раз когда наше гос-тво будет выдумывать новые законы и правила.
Именно поэтому по итогам работы генеральный и финансовый директора перейдут к п.2. вашего списка.
Вот вы замахнулись на производство… кто ж его на 1с автоматизирует…
И не фанатею я от джавы…
А бардак это больше касается штучных одинэсников, на заводах их все же восписывают немного…
По теме предприятий:
Имеем СУБД тянет пищевое производство продажу оптовую розничную все себестоимости, все техпроцессы, и еще кучу всего по учету тмц, вобщем других систем нет, то что нужно сдавать государству с ЭЦП аккуратно выгружается в типовую 1с для формирования отчетности. Кстати 1с все равно не успевает выпускать обновления под наше государство, а если и успевает то нерабочие… Так что ничем особо не удивили.
P.S. Сама СУБД разработки 80-х годов последний релиз 1996 год.
P.S.S Мир сломает себе шею за погоней упрощения программирования. Программист может писать на чем угодно от асеммблера и выше. Все остальное не программисты… Скоро программировать будут с джойстиком от плейстейшен, лиж-бы было еще проще.
И не фанатею я от джавы…
А бардак это больше касается штучных одинэсников, на заводах их все же восписывают немного…
По теме предприятий:
Имеем СУБД тянет пищевое производство продажу оптовую розничную все себестоимости, все техпроцессы, и еще кучу всего по учету тмц, вобщем других систем нет, то что нужно сдавать государству с ЭЦП аккуратно выгружается в типовую 1с для формирования отчетности. Кстати 1с все равно не успевает выпускать обновления под наше государство, а если и успевает то нерабочие… Так что ничем особо не удивили.
P.S. Сама СУБД разработки 80-х годов последний релиз 1996 год.
P.S.S Мир сломает себе шею за погоней упрощения программирования. Программист может писать на чем угодно от асеммблера и выше. Все остальное не программисты… Скоро программировать будут с джойстиком от плейстейшен, лиж-бы было еще проще.
Вот вы замахнулись на производство… кто ж его на 1с автоматизирует…
solutions.1c.ru/projects/index.html?autochoice_mode=1&parent_project_branch_id=4&project_branch_id=8&project_product_id=-1
Это далеко не полный список.
А бардак это больше касается штучных одинэсников
Штучный 1Сник для клиента стоит 2700 в час. Если клиент ему скажет: хочу что бы потратил время на наведение порядка на сервере и готов за это платить, 1С наведет порядок.
А пока ситуация такая: работы на 3 часа, но платим за 1 час, специалист сделает все что бы уложиться в срок.
Это «серьезные разработчики» могут позволить себе потратить час на запуск «DevOps», прогон и написание тестов, чаек. А инженер сопровождающий 1С должен за это время решить проблему заказчика и выехать к следующему.
«Имеем СУБД тянет пищевое производство»
А теперь давайте выпустим вашу разработку в тираж на все СНГ. И послушаем что другие люди скажут о вашем продукте.
Как вы думаете?
Скоро программировать будут с джойстиком от плейстейшен, лиж-бы было еще проще.
Если это будет решать задачи бизнеса то не вижу в этом ничего плохого.
В конце концов вы почему то свое решение не стали на ассемблере писать, а взяли готовую СУБД.
Это далеко не полный список.
Рискну предположить, что львиная доля предприятий из этого списка автоматизировали при помощи 1с:ERP всё что угодно, но не производственные участки.
А производственные на чем?
На C# / Java с нуля написали свои нетленки?
На C# / Java с нуля написали свои нетленки?
А производственные на чем?
Скорее всего, на специализированных продуктах, заточенных под отрасль.
А в отраслях, для которых таковых нет (или не было на момент разработки) — да, с нуля.
А можно пару примеров специализированных продуктов?
Ничего кроме SAP/Java и не вспоминается…
Ничего кроме SAP/Java и не вспоминается…
Согласно анализу Panorama Consulting[18], по состоянию на 2010 год поставщики ERP-систем разделены на три группы по мере уменьшения доли присутствия на рынке:
SAP (24 %), Oracle (18 %), Microsoft (11 %);
Epicor, Sage, Infor, IFS, QAD, Lawson, Ross — 11 % на всех;
ABAS, Activant Solutions, Baan, Bowen and Groves, Compiere, Exact, Netsuite, Visibility, Blue Cherry, HansaWorld, Intuitive, Syspro.
Третья группа и плюс не представленные поставщики заняли в общей сложности 36 % рынка. Распределение поставщиков на рынке зависит от масштаба заказчиков, так, в сегменте ERP для организаций с выручкой более 1 млрд долларов у SAP — 47 %, у Oracle — 32 %, у Microsoft — 4 %, тогда как в сегменте организаций с выручкой до $25 млн у SAP — 22 %, у Oracle — 23 %, у Microsoft — 16 %.
Ситуация на региональных рынках может отличаться от мировой, так, на российском рынке по состоянию на 2010 год IDC отмечает следующее распределение долей поставщиков: SAP — 50,5 %, 1С — 26 %[29], Oracle — 8,2 %, Microsoft — 7,4 %, Галактика — 2,4 % при общем объёме рынка $650 млн[30], на украинском: SAP — 43,4 %, IT-Enterprise[31] — 15,7 %, 1C — 13,9 %, Oracle — 11,7 %, Microsoft — 6,1 % при объёме 46,64 млн $[32], а в Бразилии около 50 % рынка принадлежит местной Totvs[pt], у SAP — 30 %[33].
ru.wikipedia.org/wiki/ERP
Открыл для себя Украинский план счетов, так непривычно, хотя это наверно лучше чем наши 76.АВ и т.д.
Плательщик НДС – посредник между настоящим плательщиком НДС и государством.
По крайней мере, в России, если я правильно понимаю, он называется налоговым агентом.
Посредник действительно называется налоговым агентом, и в России, и в Украине, но здесь как раз одна из многочисленных мелких ошибок автора статьи. Плательщиком НДС, т.е. несущим налоговые обязательства перед государством, является не конечный потребитель, как это часто (и неправильно) объясняют «на пальцах», а создатель этой самой добавленной стоимости, т.е. каждый производитель/поставщик в той цепочке, которая доводит товар от начала его создания до конечного потребителя. Конечный потребитель же покрывает их расходы на уплату этого налога косвенно, просто приобретая товар с увеличенной стоимостью. Т.е. предприятие в данном случае не является посредником, сиречь, налоговым агентом.
Посредник (налоговый агент, «плательщик НДС») не платит НДС. Вообще. Весь НДС, который он перечисляет государству и другим налоговым агентам, он получает от конечного потребителя. Ни одной своей копейки он не тратит на этот налог. Или есть исключения?
Со своих издержек обращения тоже платит.
Есть исключения.
Главное — механизм взаимозачёта/компенсации/возмещения. Для операций с небольшой долей добавленной стоимости (неглубокая переработка, перепродажа с небольшой маржой) большая часть суммы, полученной от покупателя по графе в выставленном ему счёте «в том числе НДС» не переводится государству, а компенсирует аналогичные графы в выставленных продавцу счетах от его поставщиков. Вплоть до того, что государство становится должным продавцу и даже выплачивает этот долг.
Ещё заметное — возникновение обязанности уплаты НДС не по факту получения денег от покупателя, а по факту отгрузки товара, выполнения работ, оказания услуг и т. п., если оплату получает продавец позже или даже вообще не получает. Когда и если получит, то произойдет компенсация покупателем уже уплаченного продавцом налога.
В целом, покупатель товара, облагаемого НДС, лишь компенсирует продавцу уже уплаченный как прямо, так и косвенно (через НДС в счетах поставщиков) государству НДС из своих оборотных и не очень средств. Да, есть механизмы сведения к минимуму «кассового разрыва» по НДС, типа с покупателя брать предоплату, а поставщикам платить только после поступления денег от покупателя, но в общем случае схема именно «сначала платим НДС прямо или косвенно, а лишь потом покупатель нам эти суммы компенсирует».
Главное — механизм взаимозачёта/компенсации/возмещения. Для операций с небольшой долей добавленной стоимости (неглубокая переработка, перепродажа с небольшой маржой) большая часть суммы, полученной от покупателя по графе в выставленном ему счёте «в том числе НДС» не переводится государству, а компенсирует аналогичные графы в выставленных продавцу счетах от его поставщиков. Вплоть до того, что государство становится должным продавцу и даже выплачивает этот долг.
Ещё заметное — возникновение обязанности уплаты НДС не по факту получения денег от покупателя, а по факту отгрузки товара, выполнения работ, оказания услуг и т. п., если оплату получает продавец позже или даже вообще не получает. Когда и если получит, то произойдет компенсация покупателем уже уплаченного продавцом налога.
В целом, покупатель товара, облагаемого НДС, лишь компенсирует продавцу уже уплаченный как прямо, так и косвенно (через НДС в счетах поставщиков) государству НДС из своих оборотных и не очень средств. Да, есть механизмы сведения к минимуму «кассового разрыва» по НДС, типа с покупателя брать предоплату, а поставщикам платить только после поступления денег от покупателя, но в общем случае схема именно «сначала платим НДС прямо или косвенно, а лишь потом покупатель нам эти суммы компенсирует».
Весь НДС, который он перечисляет государству и другим налоговым агентам, он получает от конечного потребителя
Неа, плательщик НДС как раз платит НДС из собственных средств. А от конечного потребителя он получает возмещение. Разница между налоговым агентом и плательщиком налога достаточно определённая. Налоговый агент не несёт налоговых обязательств перед государством, он только перечисляет чужие деньги. А плательщик налога несёт прямые налоговые обязательства. Если предприятие-плательщик НДС, например, отгрузило клиенту товар, но ещё не получило никакой оплаты, оно уже имеет собственную задолженность перед государством по НДС, и должно его платить. Поэтому плательщик НДС — не налоговый агент.
Ваш и предыдущие посты выглядят как возражения, а по факту являются подтверждением. В любом случае «плательщик НДС» не тратит своих денег на этот налог. Даже если он его платит из собственных средств до того как получит возмещение/компенсацию (как это не называй). Это обычная ситуация — возникает «налоговый кредит». Как будто выдает кредит государству, беспроцентный, конечно. И обязательно вернет его, когда получит возмещение/компенсацию от настоящего плательщика НДС — конечного потребителя.
Конечно, он может не создавать «добавленную стоимость» и работать в убыток, тогда да, он будет платить НДС из своих средств… но вряд ли это будет долго продолжаться.
Конечно, он может не создавать «добавленную стоимость» и работать в убыток, тогда да, он будет платить НДС из своих средств… но вряд ли это будет долго продолжаться.
В любом случае «плательщик НДС» не тратит своих денег на этот налог.
Ну как это «не тратит своих»? Именно свои и тратит, из собственного кармана, сиречь расчетного счета.
Вот допустим, это торговое предприятие. Оно приобрело товар у дистрибьютора, и продало его конечному покупателю. По вашей же логике получается, что оно не тратит своих денег на приобретение товара, всё оплачивает покупатель. Но ведь это не так. И с НДС абсолютно то же самое.
Это обычная ситуация — возникает «налоговый кредит». Как будто выдает кредит государству, беспроцентный, конечно.
А налоговый кредит — это вообще другое :)
Налоговый кредит — это входящий НДС. Если предприятие купило, допустим, у дистрибьютора товар на 100 денег с НДС 20 денег, у него будет налоговый кредит 20 денег. Это считается суммой предварительно уплаченного налога.
Потом предприятие продало этот товар конечному покупателю за 150 денег, с НДС 30 денег, соответственно, его задолженность по налоговым обязательствам будет 30-20 = 10 денег.
Поймите же, бухгалтерия — это точная наука. В ней нет места домыслам, собственным представлениям и т.д. Если что не соответствует определению, например, пресловутый «налоговый агент», то не нужно и пытаться натягивать условия, что оно якобы примерно так работает, значит, можно называть.
Тогда самоокупаемый бизнес вообще ничего не тратит из своих денег, не так ли?
Нет, в основном бизнес по другому работает: вкладываешь свои деньги, а потом надеешься, что сможет возместить их за счёт платежей своих клиентов. С НДС то же самое в общем случае отгружаешь товар, платишь налог из своих денег и надеешься, что покупатель тебе возместит все затраты, включая уплаченный налог, да ещё и в плюсе останешься.
Нет, в основном бизнес по другому работает: вкладываешь свои деньги, а потом надеешься, что сможет возместить их за счёт платежей своих клиентов. С НДС то же самое в общем случае отгружаешь товар, платишь налог из своих денег и надеешься, что покупатель тебе возместит все затраты, включая уплаченный налог, да ещё и в плюсе останешься.
Автор не понимает, что такое амортизация! С какой это радости амортизация уменьшает стоимость основных средств. Это не так! И вообще бухгалтерская амортизация к износу не имеет ровно никакого отношения.
Для меня загадка, почему в 90% учебниках про амортизацию написана какая-то ересь. Что амортизационные отчисления — это деньги на покупку нового оборудования, когда нынешнее придёт в негодность. Полный бред. Почему он так укоренился.
Амортизация — это всего лишь способ учёта стоимости основных средств в себестоимости продукции или услуг.
Пример. Вы купили авто за 1 млн. и решили стать таксистом. Бензин вам обходится 4 руб/км, ещё 1 руб/км техобслуживание, пусть ещё 3 руб/км страховка. Итого 8 руб/км — себестоимость эксплуатации автомобиля? А вот и нет. Надо как-то учесть стоимость самого автомобиля. Это и есть амортизация — распределение инвестиции на покупку основного средства на себестоимость.
Пусть мы хотим полностью самортизировать машину за 333 тыс. км. Тогда амортизация 1 млн. руб.
(стоимость покупки авто) составит 3 руб/км. Итого общая себестоимость эксплуатации 11 руб/км. Вот что такое амортизация, и к текущей стоимости авто (пусть даже после 333 тыс км) она не имеет ровным счётом никакого отношения.
Для меня загадка, почему в 90% учебниках про амортизацию написана какая-то ересь. Что амортизационные отчисления — это деньги на покупку нового оборудования, когда нынешнее придёт в негодность. Полный бред. Почему он так укоренился.
Амортизация — это всего лишь способ учёта стоимости основных средств в себестоимости продукции или услуг.
Пример. Вы купили авто за 1 млн. и решили стать таксистом. Бензин вам обходится 4 руб/км, ещё 1 руб/км техобслуживание, пусть ещё 3 руб/км страховка. Итого 8 руб/км — себестоимость эксплуатации автомобиля? А вот и нет. Надо как-то учесть стоимость самого автомобиля. Это и есть амортизация — распределение инвестиции на покупку основного средства на себестоимость.
Пусть мы хотим полностью самортизировать машину за 333 тыс. км. Тогда амортизация 1 млн. руб.
(стоимость покупки авто) составит 3 руб/км. Итого общая себестоимость эксплуатации 11 руб/км. Вот что такое амортизация, и к текущей стоимости авто (пусть даже после 333 тыс км) она не имеет ровным счётом никакого отношения.
Несколько спутано.
Во-первых к рыночной стоимости и реальному износу, амортизация действительно имеет условное отношение. Но это не оттого, что они говорят о принципиально разных вещах, а того, что амортизация — это предельно упрощённое для применения в учёте понимание того самого износа. Ведь автомобиль в бухучёте — это не столько товарная цена per se, сколько оценка приносимой автомобилем пользы.
Как амортизация рассчитывается? Вот вы написали, что мы хотим самортизировать машину за 333 тыс. километров. Откуда взялось это число? Может быть машины разваливаются через 100 тысяч, а может ездят не менее 3 миллионов? Бухгалтерия — это тот же компьютер, в неё нет «естественных» величин, все константы должны откуда-то браться.
Это наша оценка того, через сколько автомобиль станет нам бесполезен. Итак, мы берём справочные нормативы (в частности ОКОФ) и определяем срок полезного использования (те самые 333 тыс. км., хотя обычно считают в сроке эксплуатации).
То есть в момент приобретения автомобиля мы решили, что через 333 тыс. км. он станет нам бесполезен. Соответственно после 333 тыс. км. его стоимость в бухгалтерском учёте (то, сколько ещё пользы он нам принесёт) становится равна 0 в полном соответствии с нашим прогнозом. И отсюда же идут амортизационные отчисления: к моменту когда автомобиль станет бесполезен мы должны иметь возможность купить новый.
Во-первых к рыночной стоимости и реальному износу, амортизация действительно имеет условное отношение. Но это не оттого, что они говорят о принципиально разных вещах, а того, что амортизация — это предельно упрощённое для применения в учёте понимание того самого износа. Ведь автомобиль в бухучёте — это не столько товарная цена per se, сколько оценка приносимой автомобилем пользы.
Как амортизация рассчитывается? Вот вы написали, что мы хотим самортизировать машину за 333 тыс. километров. Откуда взялось это число? Может быть машины разваливаются через 100 тысяч, а может ездят не менее 3 миллионов? Бухгалтерия — это тот же компьютер, в неё нет «естественных» величин, все константы должны откуда-то браться.
Это наша оценка того, через сколько автомобиль станет нам бесполезен. Итак, мы берём справочные нормативы (в частности ОКОФ) и определяем срок полезного использования (те самые 333 тыс. км., хотя обычно считают в сроке эксплуатации).
То есть в момент приобретения автомобиля мы решили, что через 333 тыс. км. он станет нам бесполезен. Соответственно после 333 тыс. км. его стоимость в бухгалтерском учёте (то, сколько ещё пользы он нам принесёт) становится равна 0 в полном соответствии с нашим прогнозом. И отсюда же идут амортизационные отчисления: к моменту когда автомобиль станет бесполезен мы должны иметь возможность купить новый.
Да ну не так! Допустим я решила вести «одноразовый» бизнес. С самого начала запланировала: развалится машина — закроюсь. Я не планирую больше ничего обновлять. Вопрос: амортизацию мне надо начислять? Ответ: да.
Открою секрет. Любой предприниматель хочет, чтобы амортизационные отчисления были выше, и оборудование «изнашивалось» быстрее. What?!
Это позволяет в налоговом учёте повышать себестоимость, т.е. расходы, т.е. снижать прибыль, т.е. уменьшать налоги. Именно поэтому государство устанавливает минимальные сроки амортизации для различного оборудования, чтобы бизнес не хитрил. Именно поэтому ускоренная амортизация — это льгота, установленная для малого бизнеса.
Не надо путать амортизацию с отчислениями на капитальный ремонт и прочее. А закупка новых средств даже взамен старых — это, извините, инвестиции, и делаются они из прибыли или в кредит.
Открою секрет. Любой предприниматель хочет, чтобы амортизационные отчисления были выше, и оборудование «изнашивалось» быстрее. What?!
Это позволяет в налоговом учёте повышать себестоимость, т.е. расходы, т.е. снижать прибыль, т.е. уменьшать налоги. Именно поэтому государство устанавливает минимальные сроки амортизации для различного оборудования, чтобы бизнес не хитрил. Именно поэтому ускоренная амортизация — это льгота, установленная для малого бизнеса.
Не надо путать амортизацию с отчислениями на капитальный ремонт и прочее. А закупка новых средств даже взамен старых — это, извините, инвестиции, и делаются они из прибыли или в кредит.
Ок, меня сбил незнакомый термин «амортизационные отчисления», заставив предположить отчисления в натуральной, если так можно выразиться, форме.
Но в целом, если отойти от налогового учёта и попытаться понять что должен увидеть бухгалтер (а через него и руководитель) в амортизации, то одним из ответов будет: «намёк на покупку замены». Разумеется, если нет иных способов оценить эту потребность…
Возможно, чтобы понять чуть точнее что я имею ввиду, представьте, что вы писали о «белой» амортизации для налоговой, а я пишу о «чёрной», приближенной к реальности. При этом одна из ключевых мыслей: что «чёрная» амортизация вообще бывает и что на ней проще объяснять понятие, чем на «белой».
Но в целом, если отойти от налогового учёта и попытаться понять что должен увидеть бухгалтер (а через него и руководитель) в амортизации, то одним из ответов будет: «намёк на покупку замены». Разумеется, если нет иных способов оценить эту потребность…
Возможно, чтобы понять чуть точнее что я имею ввиду, представьте, что вы писали о «белой» амортизации для налоговой, а я пишу о «чёрной», приближенной к реальности. При этом одна из ключевых мыслей: что «чёрная» амортизация вообще бывает и что на ней проще объяснять понятие, чем на «белой».
Это не намёк на покупку замены, это констатация факта «деньги на покупку отбили, дальше чистая прибыль».
Тонкость: амортизация существует и в некоммерческих организациях, где никакого «отбили» может не существовать в принципе.
Если есть амортизация, значит есть основные средства и себестоимость продукции. По себестоимости «отбили», а как компенсируется себестоимость — дело десятое. Главное, что стоимость основных средств полностью перенесена на себестоимость и дальше в ней не учитывается.
Нет, себестоимость совершенно необязательна для существования амортизации.
Погранзастава, не производящая ровным счётом ничего, тоже имеет ОС и тоже их амортизирует. И также может амортизировать ОС какой-нибудь фонд борьбы с раком. Например, чтобы объяснить источнику пожертвований почему мы уже третий стол в бухгалтерию закупаем (вот видите, у нас столы изнашивались/амортизировались уже 8 лет, пора менять).
Конечно без себестоимости потребность в понятии амортизации меньше и можно её не считать. Но это не повод утверждать, что за пределами себестоимости амортизации не существует.
Погранзастава, не производящая ровным счётом ничего, тоже имеет ОС и тоже их амортизирует. И также может амортизировать ОС какой-нибудь фонд борьбы с раком. Например, чтобы объяснить источнику пожертвований почему мы уже третий стол в бухгалтерию закупаем (вот видите, у нас столы изнашивались/амортизировались уже 8 лет, пора менять).
Конечно без себестоимости потребность в понятии амортизации меньше и можно её не считать. Но это не повод утверждать, что за пределами себестоимости амортизации не существует.
Погранзастава производит услугу по охране границы и продаёт её государству по себестоимости. :) Часть себестоимости — амортизация основных средств. То же и с фондом борьбы с раком: он производит какие-то работы, оказывает какое-то услуги, и у них есть себестоимость. Он может это делать безвозмездно, надеясь на пожертвования, но если пожертвований не будет, то фонд, как минимум, приостановит деятельность, потому что ему нечем будет оплачивать себестоимость своих работ и услуг.
Это наша оценка того, через сколько автомобиль станет нам бесполезен
Амортизация — это не наша оценка. Сроки амортизации на все виды основных средств определены на законодательном уровне. Более того, амортизация совершенно не показывает, что нам пора выводить какое-то ОС из эксплуатации. Основная цель амортизационных отчислений — регулировать долю участия основных средств в формировании себестоимости. Чтобы предприятия после приобретения ОС разносили их на себестоимость равномерно, а не заваливали прибыль в каком-то периоде в ноль (при этом, соответственно, не платя налог на прибыль).
Мы ведь говорим о том, как понять бухгалтерский учёт, а не о том, как сдать отчётность в налоговую, поэтому нагляднее будет вместо требований инструкций привести пример что можно при помощи понятия «амортизация» посчитать.
Конечно, когда наш учёт выходит из подсчёта начинает формировать показатели для государственного контроля, законодатель начинает ограничивать нас в отношении того, какими могут быть наши оценки. Но в пределах установленных законом ограничений срок полезного использования определяется налогоплательщиком самостоятельно на дату ввода в эксплуатацию данного объекта амортизируемого имущества (ст. 258 НК РФ)
Мне в принципе кажется нездоровым подход, когда бухгалтерский учёт рассматривается как средство для сдачи отчётов(в том числе налоговых). За пределами же налогов ПБУ 6/01 вполне позволяет начислять амортизацию именно исходя из предполагаемого объема продукции (работ) за весь срок полезного использования объекта основных средств.
Конечно, когда наш учёт выходит из подсчёта начинает формировать показатели для государственного контроля, законодатель начинает ограничивать нас в отношении того, какими могут быть наши оценки. Но в пределах установленных законом ограничений срок полезного использования определяется налогоплательщиком самостоятельно на дату ввода в эксплуатацию данного объекта амортизируемого имущества (ст. 258 НК РФ)
Мне в принципе кажется нездоровым подход, когда бухгалтерский учёт рассматривается как средство для сдачи отчётов(в том числе налоговых). За пределами же налогов ПБУ 6/01 вполне позволяет начислять амортизацию именно исходя из предполагаемого объема продукции (работ) за весь срок полезного использования объекта основных средств.
Но в пределах установленных законом ограничений срок полезного использования определяется налогоплательщиком самостоятельно на дату ввода в эксплуатацию данного объекта амортизируемого имущества
Ну а толку? Подавляющее большинство ОС всегда имеют срок полезного использования значительно больший, чем в пределах установленных законом ограничений. И никакой пользы для управления предприятия показатели амортизации и остаточной стоимости в себе несут, кроме расчета той самой себестоимости.
Так что вы правы, ситуация с бухучетом у нас достаточно нездоровая. Но имеем что имеем.
Обратите внимание, что вы продолжаете описывать амортизацию в рамках установленных законом ограничений, предполагая что бухучёт есть исключительно порождение законов. Именно это и есть, то что я называю «нездоровым», а отнюдь не несоответствие требований ОКОФ времени износа.
Бухучет существует вне зависимости от того, прописан он в законах или нет. Если представить на минутку, что мы не платим никуда налогов и не сдаём никуда отчётность — бухучёт всё ещё останется. И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости? При помощи той же амортизации. Высчитывая её исходя из понимаемого в каждом конкретном случае срока полезного использования. В том числе понимая его как время от покупки до выбрасывания.
Конечно «износ» — это очень грубое, первое упрощение понятия амортизации. Амортизация также пытается вобрать в себя такие вещи как «моральное устаревание», «востребованность» и так далее. Но говорить, что амортизация не имеет отношения к износу это как говорить, что комплексные числа не имеют отношения к числу яблок на столе(hint: целые числа — часть множества комплексных).
Бухучет существует вне зависимости от того, прописан он в законах или нет. Если представить на минутку, что мы не платим никуда налогов и не сдаём никуда отчётность — бухучёт всё ещё останется. И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости? При помощи той же амортизации. Высчитывая её исходя из понимаемого в каждом конкретном случае срока полезного использования. В том числе понимая его как время от покупки до выбрасывания.
Конечно «износ» — это очень грубое, первое упрощение понятия амортизации. Амортизация также пытается вобрать в себя такие вещи как «моральное устаревание», «востребованность» и так далее. Но говорить, что амортизация не имеет отношения к износу это как говорить, что комплексные числа не имеют отношения к числу яблок на столе(hint: целые числа — часть множества комплексных).
>И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости?
Совсем не обязательно так, как вы привыкли воспринимать. В любой ситуации данные приводятся к такому виду, который подходит для принятия управленческих решений. На ваш вопрос возможны варианты ответа:
— никак
— единовременно перенося стоимость приобретенных ОС на себестоимость продукции
— в соответствии с фактическим износом
— в соответствии с проводимой переоценкой
Совсем не обязательно так, как вы привыкли воспринимать. В любой ситуации данные приводятся к такому виду, который подходит для принятия управленческих решений. На ваш вопрос возможны варианты ответа:
— никак
— единовременно перенося стоимость приобретенных ОС на себестоимость продукции
— в соответствии с фактическим износом
— в соответствии с проводимой переоценкой
Первые два пункта в основном не про то как считать, а про то как не считать. Особенно если рассмотреть пример с машиной. Конечно можно не вести учёт вообще, в ситуации «анархии» нас ничто к учёту не обязывает. Но если учёт сложный, то оно потребуется.
Формализацией и апроксимацией последних двух пунктов и является амортизация.
Грубая и далёкая от оригинала апроксимация? Да.
Не существует за пределами налоговой отчётности? Нет.
Я не говорю, что амортизация нужна везде и всегда. Я только говорю, что понятие амортизации шире чем её применение при сдаче налоговой отчётности. И оттого возражаю, когда некоторое понимание амортизации объявляется «невозможным» по причине противоречия требованиям налоговой.
Формализацией и апроксимацией последних двух пунктов и является амортизация.
Грубая и далёкая от оригинала апроксимация? Да.
Не существует за пределами налоговой отчётности? Нет.
Я не говорю, что амортизация нужна везде и всегда. Я только говорю, что понятие амортизации шире чем её применение при сдаче налоговой отчётности. И оттого возражаю, когда некоторое понимание амортизации объявляется «невозможным» по причине противоречия требованиям налоговой.
Подозреваю, что в реальной жизни, без необходимости соответствовать нормам НК и/или ПБУ, амортизацию как раз и не будут считать. Не нужна она совершенно ни для каких целей управления любым предприятием. Амортизация — искусственное, можно сказать «научное», понятие. Очень органично такие понятия смотрятся в рассуждениях Карла Маркса, но возьмите любую книгу по финансовому менеджменту или инвестициям, скорее всего никакой амортизации там не будет даже упомянуто.
Нет такой цели управления действующим предприятием как вычисление «доли основных средств в себестоимости». Управление идет через текущий денежный поток с целями максимизации выручки, минимизации затрат и оборотных средств.
Приобретение основных средств — решение инвестиционное. Пока ОС не приобретено нет амортизации, т.к. нет учета. После того как ОС приобретено амортизация никому не нужна, менеджмент управляет тем что есть и знание о том, что на текущий момент начислено 20% или 70% амортизации никак не поможет производить и продавать продукцию.
Нет такой цели управления действующим предприятием как вычисление «доли основных средств в себестоимости». Управление идет через текущий денежный поток с целями максимизации выручки, минимизации затрат и оборотных средств.
Приобретение основных средств — решение инвестиционное. Пока ОС не приобретено нет амортизации, т.к. нет учета. После того как ОС приобретено амортизация никому не нужна, менеджмент управляет тем что есть и знание о том, что на текущий момент начислено 20% или 70% амортизации никак не поможет производить и продавать продукцию.
Вообще-то нет, управление организацией не сводится к управлению денежным потоком.
После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Иначе у нас инвестиции превращаются в выбрасывание денег.
После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Иначе у нас инвестиции превращаются в выбрасывание денег.
> Вообще-то нет, управление организацией не сводится к управлению денежным потоком.
Может, и не сводится. Но эту точку зрения вы не обосновали. Вопрос ведь не в этом. Вопрос в том, нужен ли учет амортизации для принятия оперативных решений.
> После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Именно. Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»? И чем поможет учет амортизации в увеличении эффективности использования ОС?
Может, и не сводится. Но эту точку зрения вы не обосновали. Вопрос ведь не в этом. Вопрос в том, нужен ли учет амортизации для принятия оперативных решений.
> После того, как ОС приобретено нам надо бы ещё понять насколько эффективно оно используется, чтобы понять можно ли его использовать эффективнее. Это как минимум.
Именно. Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»? И чем поможет учет амортизации в увеличении эффективности использования ОС?
>Но эту точку зрения вы не обосновали.
Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
>Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»?
Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена. Мы делаем на нём болты — столько сколько продаём, а продаём — сколько у нас покупают. Вопрос: успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства? Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка?
А то, если у нас продажа болтов зарплату рабочего, материалы, аренду и пр. отбивают (вроде поток денежный в плюсе), но оставшихся денег не хватает ни на что и, когда станок сломается, итоговый результат с учётом его покупки будет отрицательным.
Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
>Но какой аспект эффективного использования ОС выходит за рамки «увеличить выручку, уменьшить затраты и оборотные средства»?
Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена. Мы делаем на нём болты — столько сколько продаём, а продаём — сколько у нас покупают. Вопрос: успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства? Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка?
А то, если у нас продажа болтов зарплату рабочего, материалы, аренду и пр. отбивают (вроде поток денежный в плюсе), но оставшихся денег не хватает ни на что и, когда станок сломается, итоговый результат с учётом его покупки будет отрицательным.
>>Но эту точку зрения вы не обосновали.
>Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
В этом диалоге речь даже не об амортизации. А о том, сводится ли оперативное управление к управлению денежным потоком. Я считаю, что в широком смысле именно к нему и сводится. Прекрасно понимаю что к этим словам легко придраться по сути и хотел бы уклониться от ухода дискуссии в этом направлении.
>Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена.
Нет, терминологические точки над i я расставил сразу, не надо пытаться подменять термины. Проведены не затраты, а инвестиции. Затраты появляются в процессе эксплуатации этого ОС.
>Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка
Решение о продаже станка будет принято если его текущая стоимость выше дисконтированного к текущему моменту ожидаемому чистому результату его работы. И не будет принято в противоположном случае. Даже если
>итоговый результат с учётом его покупки будет отрицательным.
Такова жизнь, инвестиционный (предпринимательский) риск предполагает что не все инвестиции дадут положительный результат. Тем не менее, любую инвестицию доводят до конца. Нет смысла продавать что-то за бесценок, если это что-то генерирует положительный денежный поток превышающий его текущую стоимость. И наоборот, нет смысла заниматься производством, которое не генерирует денежного потока сравнимого с текущей рыночной стоимостью оборудования.
И, все-таки, хотелось бы услышать. Каким образом ежемесячное начисление амортизации, т.е. ежемесячное перекладывание каких-то заранее придуманных чисел с дебета одного счета в кредит другого, поможет менеджменту предприятия в принятии решений о судьбе станка. Или наоборот, отсутствие учета амортизации помешает принять правильное решение.
>Очень тяжело что-то обосновывать, когда любой твой аргумент отбрасывают со словами «не нужен».
В этом диалоге речь даже не об амортизации. А о том, сводится ли оперативное управление к управлению денежным потоком. Я считаю, что в широком смысле именно к нему и сводится. Прекрасно понимаю что к этим словам легко придраться по сути и хотел бы уклониться от ухода дискуссии в этом направлении.
>Например: мы купили дорогой станок. Затрата (в аспекте выплаты) уже произведена.
Нет, терминологические точки над i я расставил сразу, не надо пытаться подменять термины. Проведены не затраты, а инвестиции. Затраты появляются в процессе эксплуатации этого ОС.
>Или надо принимать какие-то резкие управленческие действия вплоть до продажи станка
Решение о продаже станка будет принято если его текущая стоимость выше дисконтированного к текущему моменту ожидаемому чистому результату его работы. И не будет принято в противоположном случае. Даже если
>итоговый результат с учётом его покупки будет отрицательным.
Такова жизнь, инвестиционный (предпринимательский) риск предполагает что не все инвестиции дадут положительный результат. Тем не менее, любую инвестицию доводят до конца. Нет смысла продавать что-то за бесценок, если это что-то генерирует положительный денежный поток превышающий его текущую стоимость. И наоборот, нет смысла заниматься производством, которое не генерирует денежного потока сравнимого с текущей рыночной стоимостью оборудования.
И, все-таки, хотелось бы услышать. Каким образом ежемесячное начисление амортизации, т.е. ежемесячное перекладывание каких-то заранее придуманных чисел с дебета одного счета в кредит другого, поможет менеджменту предприятия в принятии решений о судьбе станка. Или наоборот, отсутствие учета амортизации помешает принять правильное решение.
>Нет смысла продавать что-то за бесценок, если это что-то генерирует положительный денежный поток превышающий его текущую стоимость.
Эмм… а как это сравнивать? Расстояние со скоростью (стоимость с потоком) сравнивается только при добавлении фактора времени. Вот для превращение стоимости оборудование в поток его обесценивания путём деления на предполагаемый срок полезного использования и будет одним из возможных смыслов амортизации. Более простым, чем учёт для налоговой, на мой взгляд.
Соответственно получение потока для сравнения с потоком и поможет принять решение. Потому что сто тысяч морских миль с десятью узлами не сравниваются.
Эмм… а как это сравнивать? Расстояние со скоростью (стоимость с потоком) сравнивается только при добавлении фактора времени. Вот для превращение стоимости оборудование в поток его обесценивания путём деления на предполагаемый срок полезного использования и будет одним из возможных смыслов амортизации. Более простым, чем учёт для налоговой, на мой взгляд.
Соответственно получение потока для сравнения с потоком и поможет принять решение. Потому что сто тысяч морских миль с десятью узлами не сравниваются.
>сравнивается только при добавлении фактора времени
эм… слово «дисконтированный» вам о чем-нибудь говорит? Именно так и учитывается фактор времени.
Рассуждений про связь начисляемой амортизации со временем, честно говоря, не понял. Вне зависимости от того, какой способ начисления амортизации выбран, всегда существует весьма простая функция А(t), определяющая размер амортизации начисленной к моменту времени t. Именно потому я и сомневаюсь в том, что кто-то реально будет учитывать амортизацию в отсутствии требований нормативных документов. Зачем учитывать то, что и так заранее известно?
эм… слово «дисконтированный» вам о чем-нибудь говорит? Именно так и учитывается фактор времени.
Рассуждений про связь начисляемой амортизации со временем, честно говоря, не понял. Вне зависимости от того, какой способ начисления амортизации выбран, всегда существует весьма простая функция А(t), определяющая размер амортизации начисленной к моменту времени t. Именно потому я и сомневаюсь в том, что кто-то реально будет учитывать амортизацию в отсутствии требований нормативных документов. Зачем учитывать то, что и так заранее известно?
А зачем учитывать поступление денежных средств, которое и так видно в банковской выписке или сумму заработной платы, которая прописана в штатном расписании?
Чтобы можно было собирать агрегирующие показатели по десяткам и сотням A(t) в различных группировках(конкретный производственный цех; отдел; филиал; направление работ). В этом и есть суть учёта: каждый конкретный показатель можно посчитать и без учёта, но чтобы их сложить, отобрать, сравнить их требуется систематизировать.
Значительная часть методов этой систематизации, как отмечено в начале поста, была разработана когда ещё не было компьютеров. Поэтому в общем и целом эти понятия можно рассматривать как наименования аргументов или параметров запроса к базе данных(которая в те времена была на бумаге).
Вот функция A(t) называется «амортизация». Я не говорю, что её сложно посчитать, не назвав «амортизацией»; я говорю, что она существует. Ну и что вообще говоря имея термин «амортизация» мы можем примерно понимать о чём идёт речь, даже когда в другой организации функция будет названа PoraNaSvaku(days)
Чтобы можно было собирать агрегирующие показатели по десяткам и сотням A(t) в различных группировках(конкретный производственный цех; отдел; филиал; направление работ). В этом и есть суть учёта: каждый конкретный показатель можно посчитать и без учёта, но чтобы их сложить, отобрать, сравнить их требуется систематизировать.
Значительная часть методов этой систематизации, как отмечено в начале поста, была разработана когда ещё не было компьютеров. Поэтому в общем и целом эти понятия можно рассматривать как наименования аргументов или параметров запроса к базе данных(которая в те времена была на бумаге).
Вот функция A(t) называется «амортизация». Я не говорю, что её сложно посчитать, не назвав «амортизацией»; я говорю, что она существует. Ну и что вообще говоря имея термин «амортизация» мы можем примерно понимать о чём идёт речь, даже когда в другой организации функция будет названа PoraNaSvaku(days)
>А зачем учитывать поступление денежных средств, которое и так видно в банковской выписке или сумму заработной платы, которая прописана в штатном расписании?
Ну и зачем?
Впрочем, не забывайте о том, что
во-первых, полный учет должен вестись по всем фактам (действиям) хозяйственной деятельности предприятия (еще раз, бухгалтерский учет ведется по фактам хозяйственной деятельности, термин «показатели», похоже, придуман вами сейчас). Начислению амортизации не соответствует никакого факта (действия). Это ключевое отличие. Во-вторых, в реальной жизни учет указанных вами фактов не ведется, например, экономическими субъектами применяющими специальные режимы налогообложения (УСН, ЕНВД, патент).
Далее я потерял мысль ваших рассуждений. Потому прошу уточнить, можете ли вы привести/придумать хотя бы один пример когда учет амортизации дает возможность принять решение, которое невозможно принять без такового учета (при этом учет всего остального, в т.ч. номинальный срок эксплуатации каждого ОС в учете присутствует и доступен принимающим решение лицам).
Также хочется вернутся вот к этому вопросу:
>успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства?
Вопрос имеет право на существование, но существуют такие вопросы разве что в слабеньких учебниках для детей. Ответ на него ни на что не влияет. Легко можно придумать два примера с ответом «успеем», но в одном рациональным действием будет продажа оборудования, а в другом продолжение его эксплуатации. Также легко придумать еще два примера с ответом «не успеем» и точно также отличающимися при этом ответе последующими рациональными действиями. Приводить примеры?
Еще раз. Понятие «амортизация» существует как теоритическое. Пик его актуальности был во времена написания «Капитала». В настоящее время изменение в экономическом укладе привели к тому, что далеко не для каждого средства производства его можно выделить даже теоретически. Потому заявлять о том, что амортизация описывает какой-то реальный физический или экономический процесс (другими словами имеет физический или экономический смысл) в общем случае неверно.
И еще один пример. Пусть человек ведет семейный бюджет. Ведет его тщательно, фиксируя буквально каждую операцию. И вот в какой-то момент решил этот человек сделать в туалете ремонт, заменив старый, хоть и работающий, унитаз на новый, красивый, высокий, удобный, с функцией подогрева сиденья. Если мы будем смотреть на этого человека глазами исследователя, мы можем сказать, что в данном случае человек потратил деньги только на свой комфорт, ведь функция-то унитаза не изменилась, а старый был вполне рабочим. Причем, т.к. комфорт от данного приобретения он будет получать в течение длительного срока, имеет место комфорт-амортизация, описывающая перенос произведенных затрат в комфорт со временем. Это же теория, почему нет? А теперь представьте реакцию этого человека, если его будут уверять, что для полноценного учета он должен определиться на какую сумму он получает дополнительного комфорта каждый месяц и каждый месяц выписывать эту сумму в специальный регистр. А если, вдруг задумается о приобретении нового унитаза, то обязательно должен сравнить, сколько еще рублей комфорта он недополучил от предыдущего, и на основании этого принимать решение. Безумие? Да, безумие. Ну так и настоящая «экономическая» амортизация столь же неточно и некорректно описывает процесс эксплуатации основных средств.
Ну и зачем?
Впрочем, не забывайте о том, что
во-первых, полный учет должен вестись по всем фактам (действиям) хозяйственной деятельности предприятия (еще раз, бухгалтерский учет ведется по фактам хозяйственной деятельности, термин «показатели», похоже, придуман вами сейчас). Начислению амортизации не соответствует никакого факта (действия). Это ключевое отличие. Во-вторых, в реальной жизни учет указанных вами фактов не ведется, например, экономическими субъектами применяющими специальные режимы налогообложения (УСН, ЕНВД, патент).
Далее я потерял мысль ваших рассуждений. Потому прошу уточнить, можете ли вы привести/придумать хотя бы один пример когда учет амортизации дает возможность принять решение, которое невозможно принять без такового учета (при этом учет всего остального, в т.ч. номинальный срок эксплуатации каждого ОС в учете присутствует и доступен принимающим решение лицам).
Также хочется вернутся вот к этому вопросу:
>успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства?
Вопрос имеет право на существование, но существуют такие вопросы разве что в слабеньких учебниках для детей. Ответ на него ни на что не влияет. Легко можно придумать два примера с ответом «успеем», но в одном рациональным действием будет продажа оборудования, а в другом продолжение его эксплуатации. Также легко придумать еще два примера с ответом «не успеем» и точно также отличающимися при этом ответе последующими рациональными действиями. Приводить примеры?
Еще раз. Понятие «амортизация» существует как теоритическое. Пик его актуальности был во времена написания «Капитала». В настоящее время изменение в экономическом укладе привели к тому, что далеко не для каждого средства производства его можно выделить даже теоретически. Потому заявлять о том, что амортизация описывает какой-то реальный физический или экономический процесс (другими словами имеет физический или экономический смысл) в общем случае неверно.
И еще один пример. Пусть человек ведет семейный бюджет. Ведет его тщательно, фиксируя буквально каждую операцию. И вот в какой-то момент решил этот человек сделать в туалете ремонт, заменив старый, хоть и работающий, унитаз на новый, красивый, высокий, удобный, с функцией подогрева сиденья. Если мы будем смотреть на этого человека глазами исследователя, мы можем сказать, что в данном случае человек потратил деньги только на свой комфорт, ведь функция-то унитаза не изменилась, а старый был вполне рабочим. Причем, т.к. комфорт от данного приобретения он будет получать в течение длительного срока, имеет место комфорт-амортизация, описывающая перенос произведенных затрат в комфорт со временем. Это же теория, почему нет? А теперь представьте реакцию этого человека, если его будут уверять, что для полноценного учета он должен определиться на какую сумму он получает дополнительного комфорта каждый месяц и каждый месяц выписывать эту сумму в специальный регистр. А если, вдруг задумается о приобретении нового унитаза, то обязательно должен сравнить, сколько еще рублей комфорта он недополучил от предыдущего, и на основании этого принимать решение. Безумие? Да, безумие. Ну так и настоящая «экономическая» амортизация столь же неточно и некорректно описывает процесс эксплуатации основных средств.
>Ну и зачем?
То есть бухучёт по-вашему вообще не нужен? Я вот не представляю, например, организации масштабов хотя бы НИИ, не говоря о чём-то большем, которая могла бы обойтись одной банковской выпиской для управленческих решений.
> учет должен вестись по всем фактам (действиям)
Вот здесь вы резко и принципиально смешали факт и действие. Факт: человек работает. Совершенно не каждый час отмечается в учёте и даже дни собираются в табели обычно пост-фактум, а не в виде ежедневных галочек на бумажке. Тем не менее с каждым днём и с каждым часом мы становимся должны человеку зарплату. Что отражается в виде периодических начислений. «Начисление зарплаты» такое же в определённом смысле виртуальное действие, как «начисление амортизации», просто зарплате соответствует факт работы, а амортизации — факт устаревания/износа.
Процесс амортизации как функция существует для анализа. Процесс амортизации как периодических записей в реестре не является его неотъемлемой частью, но возникает в бухучёте, поскольку бухгалтерский учёт основан на дискретных периодических записях-проводках.
>заявлять о том, что амортизация описывает какой-то реальный процесс в общем случае неверно.
Соглашусь. Я лишь утверждал, что заявлять будто амортизация не описывает реальный процесс также в общем случае неверно. Она может быть как связана с реальным процессом, так и оторвана от него.
То есть бухучёт по-вашему вообще не нужен? Я вот не представляю, например, организации масштабов хотя бы НИИ, не говоря о чём-то большем, которая могла бы обойтись одной банковской выпиской для управленческих решений.
> учет должен вестись по всем фактам (действиям)
Вот здесь вы резко и принципиально смешали факт и действие. Факт: человек работает. Совершенно не каждый час отмечается в учёте и даже дни собираются в табели обычно пост-фактум, а не в виде ежедневных галочек на бумажке. Тем не менее с каждым днём и с каждым часом мы становимся должны человеку зарплату. Что отражается в виде периодических начислений. «Начисление зарплаты» такое же в определённом смысле виртуальное действие, как «начисление амортизации», просто зарплате соответствует факт работы, а амортизации — факт устаревания/износа.
Процесс амортизации как функция существует для анализа. Процесс амортизации как периодических записей в реестре не является его неотъемлемой частью, но возникает в бухучёте, поскольку бухгалтерский учёт основан на дискретных периодических записях-проводках.
>заявлять о том, что амортизация описывает какой-то реальный процесс в общем случае неверно.
Соглашусь. Я лишь утверждал, что заявлять будто амортизация не описывает реальный процесс также в общем случае неверно. Она может быть как связана с реальным процессом, так и оторвана от него.
> Потому заявлять о том, что амортизация описывает какой-то реальный физический или экономический процесс (другими словами имеет физический или экономический смысл) в общем случае неверно.
Амортизация описывает экономический процесс «расходования» имущества в процессе владения им.
> А теперь представьте реакцию этого человека, если его будут уверять, что для полноценного учета он должен определиться на какую сумму он получает дополнительного комфорта каждый месяц и каждый месяц выписывать эту сумму в специальный регистр.
Я не веду полноценного учёта, но при покупке чего-то на замену имеющегося просто ради комфорта, прикидываю сколько в день я буду платить ради этого комфорта исходя из предполагаемого срока эксплуатации и остаточной стоимости на его конец. То есть по сути считаю как изменится себестоимость одного моего дня в разрезе «долгоиграющих» покупок и стоит ли оно того.
Амортизация описывает экономический процесс «расходования» имущества в процессе владения им.
> А теперь представьте реакцию этого человека, если его будут уверять, что для полноценного учета он должен определиться на какую сумму он получает дополнительного комфорта каждый месяц и каждый месяц выписывать эту сумму в специальный регистр.
Я не веду полноценного учёта, но при покупке чего-то на замену имеющегося просто ради комфорта, прикидываю сколько в день я буду платить ради этого комфорта исходя из предполагаемого срока эксплуатации и остаточной стоимости на его конец. То есть по сути считаю как изменится себестоимость одного моего дня в разрезе «долгоиграющих» покупок и стоит ли оно того.
Вопрос: успеем ли мы за время работы станка возместить затраты на его приобретение при имеющемся объёме продаж и производства?
А как вам на этот вопрос ответит амортизация? Она не коррелирует со сроком эксплуатации станка.
И даже если бы коррелировала. Зачем её начислять-то? Паспортный срок эксплуатации — константа. Вычислить оставшийся срок эксплуатации на текущий момент времени — третьеклассник в уме сможет.
В пятый раз, пожалуйста: для амортизации как понятия коррелирует. Причём именно со сроком эксплуатации, как владелец организации его понимает во временном или в натуральном выражении.
Да, требования налогового учёта или чего-то ещё могут сдвигать амортизацию за пределы этого срока. Это не означает, что амортизация как понятие не применима за пределами налогового учёта.
Потому что когда у нас надо обсчитывать сотни и тысячи ОС в разрезе десятков направлений деятельности, то неплохо бы все эти вопросы как-то систематизировать. Систематизацией таких вещей в общем и занимается бухгалтерский учёт. В частности при помощи понятия амортизации.
Да, требования налогового учёта или чего-то ещё могут сдвигать амортизацию за пределы этого срока. Это не означает, что амортизация как понятие не применима за пределами налогового учёта.
Потому что когда у нас надо обсчитывать сотни и тысячи ОС в разрезе десятков направлений деятельности, то неплохо бы все эти вопросы как-то систематизировать. Систематизацией таких вещей в общем и занимается бухгалтерский учёт. В частности при помощи понятия амортизации.
В пятый раз, пожалуйста: для амортизации как понятия коррелирует.
Что такое «амортизация как понятие»? Вы предлагаете вести две амортизации, одну, рассчитанную на полезный срок эксплуатации ОС для управленческого учета, другую регламентированную для бухгалтерии?
ОК, а кто должен считать этот полезный срок эксплуатации, для всего зоопарка ОС, который бывает на предприятиях? Да и, собственно, зачем? Ну вот вы сможете сделать оценку, что при выпуске, скажем, 10 тыс. изделий станок окупит свои капитальные инвестиции. Какой у него должен быть срок амортизации? Считаем среднюю загрузку станка, и на основании этого прикидываем, сколько лет он будет эти 10 тыс. изделий производить? А если продажи вырастут или упадут?
Или ладно, то станок. Ну допустим, это туалет для рабочих. У него ожидаемый срок эксплуатации лет 50 с тремя-четырьмя капремонтами. Какой там ставим срок амортизации? 50 лет?
Ну в общем-то если в организации по каким-то причинам бухгалтерский и налоговый учёт полностью разделены, то да, можно иметь именно такие две амортизации.
Но хотел я сказать не это. Хотел я сказать, что для того, чтобы понять что такое амортизация можно (и нужно) начинать с полезного срока эксплуатации и износа. А «регламентированная» амортизация выводится из этого внесением «регламентов»(НК и ОКОФ). Но амортизация начинается не с регламента и регламент не является её неотъемлемым свойством.
Со станком наоборот: считаем стоимость станка, оцениваем его срок полезного использования (используя ОКОФ, документация производителя, здравый смысл и опыт). Делим одно на другое — получаем амортизацию. Складываем амортизацию с другими расходами на изделие и смотрим окупается у нас изделие или нет.(например при 10 тыс. окупается, а при 5 тыс. — нет)
То же с туалетом. Срок эксплуатации… ну я не особо эксперт в этих делах, но я бы закладывал до первого капитального.
Но хотел я сказать не это. Хотел я сказать, что для того, чтобы понять что такое амортизация можно (и нужно) начинать с полезного срока эксплуатации и износа. А «регламентированная» амортизация выводится из этого внесением «регламентов»(НК и ОКОФ). Но амортизация начинается не с регламента и регламент не является её неотъемлемым свойством.
Со станком наоборот: считаем стоимость станка, оцениваем его срок полезного использования (используя ОКОФ, документация производителя, здравый смысл и опыт). Делим одно на другое — получаем амортизацию. Складываем амортизацию с другими расходами на изделие и смотрим окупается у нас изделие или нет.(например при 10 тыс. окупается, а при 5 тыс. — нет)
То же с туалетом. Срок эксплуатации… ну я не особо эксперт в этих делах, но я бы закладывал до первого капитального.
>Ну в общем-то если в организации по каким-то причинам бухгалтерский и налоговый учёт полностью разделены, то да, можно иметь именно такие две амортизации.
geektimes.ru/post/298061/?reply_to=10614565#comment_10614799
Да не по каким-то, а по необходимости. Жизненной. И именно потому, что в реальности никакой амортизации нет, есть понятие используемое в одной из экономических теорий, если снять законодательные требования, то ни одного учета амортизации из этих двух не останется.
geektimes.ru/post/298061/?reply_to=10614565#comment_10614799
Да не по каким-то, а по необходимости. Жизненной. И именно потому, что в реальности никакой амортизации нет, есть понятие используемое в одной из экономических теорий, если снять законодательные требования, то ни одного учета амортизации из этих двух не останется.
>Вы предлагаете вести две амортизации, одну, рассчитанную на полезный срок эксплуатации ОС для управленческого учета, другую регламентированную для бухгалтерии?
:-)
Так в РФ очень многие организации именно и ведут два учета амортизации. Так называемый «налоговый» используется для определения базы для налога на прибыль. И так называемый «бухгалтерский» используется для определения базы налога на имущество. Именно в последнем нужно использовать ОКОФ для определения амортизационной группы.
Но! Вся эта ветка растет из предположения что было бы, если бы обязанность учитывать амортизацию не следовала ни из одного нормативного документа.
:-)
Так в РФ очень многие организации именно и ведут два учета амортизации. Так называемый «налоговый» используется для определения базы для налога на прибыль. И так называемый «бухгалтерский» используется для определения базы налога на имущество. Именно в последнем нужно использовать ОКОФ для определения амортизационной группы.
Но! Вся эта ветка растет из предположения что было бы, если бы обязанность учитывать амортизацию не следовала ни из одного нормативного документа.
Амортизация может помогать менеджменту оценивать эффективность вложений в основные средства. Знание, что за 5 лет начислено 20% амортизации по выбранному самим же менеджментом методике, поможет ему принять решение о, например, продаже по рыночной стоимости и вкладывания денег куда-то с бОльшей выгодой.
Так объясните, как именно помогать-то? Пример решения принятого на основе данных о начисленной амортизации привести можете?
А я пока контрпример приведу.
Пусть компания Альфа ведет учет всех фактов хозяйственной жизни и начисляет в бухгалтерском учете амортизацию каждого ОС (т.е. для каждого ОС выполняет ежемесячное перекладывание каких-то заранее придуманных чисел с дебета одного счета в кредит другого). Пусть компания Бета абсолютно идентична компании Альфа, за исключением того, что в компании Бета амортизация в бухгалтерском учете не начисляется. Пусть менеджмент этих компаний проводит оценку эффективности вложений в основные средства. Имеет ли менеджмент компании Альфа какие-либо преимущества в принятии решения о продаже ОС по рыночной стоимости и вкладывании денег куда-то с бОльшей выгодой по сравнению с менеджментом компании Бета?
Ответ: Нет, не имеет.
Доказательство: В любой момент времени менеджменту компании Бета доступно рассуждение вида «если бы пять лет назад при вводе основных средств в эксплуатацию был выбран такой-то метод амортизации с таким-то сроком амортизации, то в настоящее время была бы начислена амортизация в размере 20% от первоначальной стоимости». Т.е. менеджменту компании Бета доступна ровно такая же информация что и менеджменту компании Альфа, ни больше и не меньше. ч.т.д.
Замечу. Что на самом деле для принятия указанного решения амортизация нужна не больше чем численность пингвинов в Антарктиде. А нужна информация о текущей рыночной стоимости ОС (за сколько можно продать) и о ожидаемом чистом (выручка минус затраты) денежном потоке от их эксплуатации (сколько можно заработать).
А я пока контрпример приведу.
Пусть компания Альфа ведет учет всех фактов хозяйственной жизни и начисляет в бухгалтерском учете амортизацию каждого ОС (т.е. для каждого ОС выполняет ежемесячное перекладывание каких-то заранее придуманных чисел с дебета одного счета в кредит другого). Пусть компания Бета абсолютно идентична компании Альфа, за исключением того, что в компании Бета амортизация в бухгалтерском учете не начисляется. Пусть менеджмент этих компаний проводит оценку эффективности вложений в основные средства. Имеет ли менеджмент компании Альфа какие-либо преимущества в принятии решения о продаже ОС по рыночной стоимости и вкладывании денег куда-то с бОльшей выгодой по сравнению с менеджментом компании Бета?
Ответ: Нет, не имеет.
Доказательство: В любой момент времени менеджменту компании Бета доступно рассуждение вида «если бы пять лет назад при вводе основных средств в эксплуатацию был выбран такой-то метод амортизации с таким-то сроком амортизации, то в настоящее время была бы начислена амортизация в размере 20% от первоначальной стоимости». Т.е. менеджменту компании Бета доступна ровно такая же информация что и менеджменту компании Альфа, ни больше и не меньше. ч.т.д.
Замечу. Что на самом деле для принятия указанного решения амортизация нужна не больше чем численность пингвинов в Антарктиде. А нужна информация о текущей рыночной стоимости ОС (за сколько можно продать) и о ожидаемом чистом (выручка минус затраты) денежном потоке от их эксплуатации (сколько можно заработать).
Пример: покупаем станок со сроком эксплуатации 12 лет ценой в 1 200 000 с нулевой остаточной стоимостью и производительностью 100 000 деталей в год. Себестоимость одной детали без учёта стоимости станка 1 (предположим, что других основных средств и постоянных издержек нет, все остальные затраты переменные и растут строго линейно, вложения оборотных средств не нужны).
Запустили производство, проработали год, произвели 100 000 деталей, средняя отпускная цена детали составила 3, а стоимость станка «бу 1 год» на рынке 1 100 000. Оборотные итоги года: -1 200 000 расходов и 300 000 доходов, год закончился глубокими убытками. Вложение в станок было крайне убыточным, лучше продать станок и деньги под подушку положить? С другой стороны, тратили на производство детали 1, а получали 3. Прибыльность 200%? Вспоминаем про амортизацию и считаем, что за год на производство 100 000 деталей «потрачено» станка на 100 000. Реальная себестоимость детали составила 2, а прибыль от вложений в станок 1 на деталь или 100 000 за год с 1 200 000. Нас это вполне устраивает и продолжаем работать. А чтобы каждый раз при оценке эффективности вложений в станок не исследовать рынок на предмет стоимости станков «бу 1 год и 7 дней», принимаем за базовый метод начисления амортизации 1 на одну деталь с пересмотром по итогам года, то есть принимаем себестоимость детали равной 2 пока станок загружен на полную. Пока отпускная цена больше 2 и нет затаривания станок приносит прибыль.
Ответ: имеет. У компании Альфа эти данные уже есть, компании Бета нужно дать указание на их получение.
Запустили производство, проработали год, произвели 100 000 деталей, средняя отпускная цена детали составила 3, а стоимость станка «бу 1 год» на рынке 1 100 000. Оборотные итоги года: -1 200 000 расходов и 300 000 доходов, год закончился глубокими убытками. Вложение в станок было крайне убыточным, лучше продать станок и деньги под подушку положить? С другой стороны, тратили на производство детали 1, а получали 3. Прибыльность 200%? Вспоминаем про амортизацию и считаем, что за год на производство 100 000 деталей «потрачено» станка на 100 000. Реальная себестоимость детали составила 2, а прибыль от вложений в станок 1 на деталь или 100 000 за год с 1 200 000. Нас это вполне устраивает и продолжаем работать. А чтобы каждый раз при оценке эффективности вложений в станок не исследовать рынок на предмет стоимости станков «бу 1 год и 7 дней», принимаем за базовый метод начисления амортизации 1 на одну деталь с пересмотром по итогам года, то есть принимаем себестоимость детали равной 2 пока станок загружен на полную. Пока отпускная цена больше 2 и нет затаривания станок приносит прибыль.
Ответ: имеет. У компании Альфа эти данные уже есть, компании Бета нужно дать указание на их получение.
Только это у Вас не амортизация. Ни одно ОС не дешевеет по формуле, более того — многие ОС могут долгое время оставаться в одной цене. Станок, который я купил 3 года назад за 1 200 000 сейчас стоит 3 200 000, и это с учетом того что я с него обвеса (мне ненужного в производстве) снял на полляма. И да, по бухгалтерии он уже списан вроде как, его остаточная стоимость — 0. Ну или другой станок, который я купил 2 года назад за 300 тыр. Через полгода производитель не вынес и поднял цену, новый стал стоить 400 тыр, стоимость моего б/у — ориентировочно стала 350 тыр. Через год я его поднадстроил, но и подушатал, рыночная цена в таком виде — ну, скажем, 300 тыр. Через еще год он будет уже совсем утомленный, его цена станет 200 тыр. Но в таком виде я его смогу эксплуатировать и цена останется те же 200 тыр в течении 5 лет. Потом он совсем утомится и его можно будет продать по цене станины и электроники — 100 тыр, в течении лет 10.
Вопрос: как любое возможное постоянное значение в графе «амортизация» поможет мне в каждый конкретный момент времени в определении цены, за которую можно продать станок? Ну и сразу ответ: никак. Любое значение будет только мешать и создавать искажение реальной картины.
Вопрос: как любое возможное постоянное значение в графе «амортизация» поможет мне в каждый конкретный момент времени в определении цены, за которую можно продать станок? Ну и сразу ответ: никак. Любое значение будет только мешать и создавать искажение реальной картины.
Амортизация не для определения рыночной цены. Амортизация для разнесения цены покупки на себестоимость. Чтобы не получалось, что первая деталь стоит 1 200 000 с копейками, а вторая — только копейки. Методика разнесения в целях управленческого учёта целиком на ваше усмотрение. Вы можете каждый день переоценивать основные фонды по рыночным ценам, можете аппроксимировать любой формулой, можете пересматривать формулы ежедневно, применять их задним и «передним» числом. Можете вообще сразу списывать стоимость основных средств на убытки, а когда продадите по цене станины — записать на прибыль.
Это ваш учёт, никто кроме вас не знает его целей. Но если вам кажется, что не учитывать стоимость станка в себестоимости производимых их деталей как-то неправильно, то амортизация (методики — отдельный разговор) это то, что вам нужно. Если вам не интересна себестоимость продукции, то амортизация в пределах бОльших чем требует закон вам не нужна, относите её к прихотям государства и просите не заморачивать бухгалтеров вам голову ею.
Это ваш учёт, никто кроме вас не знает его целей. Но если вам кажется, что не учитывать стоимость станка в себестоимости производимых их деталей как-то неправильно, то амортизация (методики — отдельный разговор) это то, что вам нужно. Если вам не интересна себестоимость продукции, то амортизация в пределах бОльших чем требует закон вам не нужна, относите её к прихотям государства и просите не заморачивать бухгалтеров вам голову ею.
> И как в такой «анархической» ситуации мы будем определять долю основных средств в себестоимости? При помощи той же амортизации. Высчитывая её исходя из понимаемого в каждом конкретном случае срока полезного использования. В том числе понимая его как время от покупки до выбрасывания.
Совсем не обязательно. Амортизация — это именно возможность растянуть стоимость основных средств по времени при определении себестоимости, чтобы не считать, что, например, первая продажа болтов, выточенной на новом станке, ввела нас в глубокий убыток, а вторая почти чистую прибыль принесла.
Имеет ли смысл такое растягивание, как ограничивать его сверху и снизу определяется, прежде всего, интересами лица, определяющего себестоимость. Если меня интересует именно реальная прибыль, возврат моих инвестиций, а не определяемая в целях налогообложения, то я не буду растягивать амортизацию на максимально возможный срок, я буду считать «отчислениями» на амортизацию всё, что остаётся от стоимости реализации продукции после вычета обязательных расходов. И перестану считать вообще, когда вложения в ОС отобьются, дальше для меня себестоимость продукции будет состоять только из операционных расходов, всё остальное — чистая прибыль. Это как один из вариантов.
Совсем не обязательно. Амортизация — это именно возможность растянуть стоимость основных средств по времени при определении себестоимости, чтобы не считать, что, например, первая продажа болтов, выточенной на новом станке, ввела нас в глубокий убыток, а вторая почти чистую прибыль принесла.
Имеет ли смысл такое растягивание, как ограничивать его сверху и снизу определяется, прежде всего, интересами лица, определяющего себестоимость. Если меня интересует именно реальная прибыль, возврат моих инвестиций, а не определяемая в целях налогообложения, то я не буду растягивать амортизацию на максимально возможный срок, я буду считать «отчислениями» на амортизацию всё, что остаётся от стоимости реализации продукции после вычета обязательных расходов. И перестану считать вообще, когда вложения в ОС отобьются, дальше для меня себестоимость продукции будет состоять только из операционных расходов, всё остальное — чистая прибыль. Это как один из вариантов.
Все правильно, только…
> И перестану считать вообще, когда вложения в ОС отобьются, дальше для меня себестоимость продукции будет состоять только из операционных расходов,
не перестанете :-). Как инвестора вас интересует дисконтированный к начальному моменту времени результат инвестиций. Поэтому считать будете до тех пор пока инвестиция создает ненулевой денежный поток.
> всё остальное — чистая прибыль
Нет никакой прибыли. Есть процентный доход на инвестиционный капитал.
> И перестану считать вообще, когда вложения в ОС отобьются, дальше для меня себестоимость продукции будет состоять только из операционных расходов,
не перестанете :-). Как инвестора вас интересует дисконтированный к начальному моменту времени результат инвестиций. Поэтому считать будете до тех пор пока инвестиция создает ненулевой денежный поток.
> всё остальное — чистая прибыль
Нет никакой прибыли. Есть процентный доход на инвестиционный капитал.
Кроме процентного дохода на инвестиционный капитал есть вознаграждение за применение предпринимательской способности. Как инвестор, внеся 10 000 рублей в уставной капитал своего ООО, я буду считать процентный доход в виде дивидендов. И вряд ли я лично буду его дисконтировать. «Бабки отбились — повезло» скажу я себе когда получу 10 000 дивидендов, «надежней чем в банке». Но как инвестора меня не будет интересовать как генеральный директор, наёмный менеджер с, предположительно, предпринимательской способностью, распределял их, покупал основные средства или всё в оборот пускал.
А вот как менеджеру, мне надо следить насколько эффективно я их распределяю.
А вот как менеджеру, мне надо следить насколько эффективно я их распределяю.
«Амортизация — это всего лишь способ учёта стоимости основных средств в себестоимости продукции или услуг.» — не только. Это еще и способ списания затрат в налоговом учете. Многим предпринимателям выгоднее было включить дорогую покупку в состав расходов, но тут его государство закономерно осаживает, мол полегче, давай не все сразу, да, ты потратился, но нам нужны твои налоги.
Да, конечно. Просто приходится покороче писать.
Это не способ списания затрат в налоговом учёте. Это компромисс между бизнесом и государством в вопросе того, как учитывать стоимость ОС в себестоимости в целях налогообложения, прежде всего налогообложения прибыли. Государство могло бы вообще запретить списывать стоимость основных средств в себестоимость, а могло бы разрешить списывать как угодно. Первое ему очень выгодно (если не рассматривать влияние на мотивацию заниматься в бизнесом вообще), второе очень невыгодно. Бизнесу с точностью до наоборот. Существующие регламенты амортизации в целях налогового учёта — компромисс.
Никакой загадки :)
Просто до 92 года было именно такое понятие «Амортизационный фонд». И именно тот смысл, о котором вы говорите в него и вкладывался. Да и вообще, экономика предприятий была немного другая, что и говорить. :)
Очень доступно об этом изложено в статье.
А так, да, действительно устаревшая трактовка понятия «амортизация».
Просто до 92 года было именно такое понятие «Амортизационный фонд». И именно тот смысл, о котором вы говорите в него и вкладывался. Да и вообще, экономика предприятий была немного другая, что и говорить. :)
Очень доступно об этом изложено в статье.
А так, да, действительно устаревшая трактовка понятия «амортизация».
Основная и самая сложная задача бухгалтерии автоматизации бизнеса — сделать так, чтобы то, что в программе совпадало с тем, что в реальности. И это больше задача для людей, а не для программ. Задача программиста сделать так, чтобы модель в информационной системе совпадала с реальностью в достаточной мере.
счет 281 «Товары на складе»
автор, рекомендую сразу сделать уточнение, что это украинский план счетов, и указать, что в других странах и планах счетов, нумерация и сами группы могут быть другими
UFO just landed and posted this here
Если кому понравилась статья то рекомендую еще и эту:
infostart.ru/public/100093 («О чём говорят финансисты». Готовимся к финансовым проектам.)
Вот интересная статья, для «программистов» тут конечно ничего нового но если есть интерес к работе «недопрограммистов» то будет интересно почитать:
infostart.ru/public/719504 (Как появляются встречные затраты)
infostart.ru/public/100093 («О чём говорят финансисты». Готовимся к финансовым проектам.)
Вот интересная статья, для «программистов» тут конечно ничего нового но если есть интерес к работе «недопрограммистов» то будет интересно почитать:
infostart.ru/public/719504 (Как появляются встречные затраты)
Пока не стану рассказывать о Зарплате,
может пришло время написать статью продолжение про ЗРП?
Было бы очень интересно посмотреть на бухгалтерию со стороны базы данных. Основные таблицы, поля в них, реляции. Посмотреть различные подходы к проектированию базы для бухгалтерии. Рассмотреть какие преимущества и недостатки какие подходы имеют. Итп. За статью конечно спасибо, но хотелось бы больше практической информации по дизайну базы для бухлгалтерии.
Sign up to leave a comment.
Бухгалтерский учет для программистов