Вот как в Facebook затыкают рты и почему надо дождаться полного запрета Meta на россии, после чего там можно будет относительно свободно общаться. Ниже написана полная правда - я получал баны за использование слова "вата" в контексте обычных сообщений с большей долей сарказма. И в постсоветском инете ботами больше всех балуется только одна страна - россия.
Сегодня утром Reuters опубликовало материал о том, что Meta якобы временно разрешает украинским пользователям в своих соцсетях публикацию постов с хейт-спичем в отношении России. Однако на самом деле это выдернуто из контекста: в Facebook давно уже — как минимум с мая прошлого года — действует группа троллей, они целенаправленно выискивают комментарии, которые можно было бы трактовать как хейт-спич, как нарушение. Как только комментарий находится, сразу делается массовая жалоба. Сейчас, поскольку это достигло пика и количество жалоб начало превышать здравый смысл, Facebook отключил эту функцию. Этот бан в Facebook проходил автоматически — есть формальный признак хейт-спича, какие-то ключевые слова (например, «хохол», «москаль») и на этот комментарий есть какое-то количество жалоб. И человека банят. Это все было автоматически. Теперь автоматическую систему убрали.
Очередная ложь в духе соловьева и киселева. Пророссийская модерация в Facebook давит даже за слово "вата" как за призывы к насилию на национальной почве. Лично я с начала горячей фазы войны россии против Украины (фактически война началась 8 лет назад) туда ни ногой. Вот сейчас россия забанит у себя Мету, российские модераторы (точнее смотрители) отойдут от дел (переключатся на скрепный VK или еще что) и где-то к осени можно подумать о возвращении туда.
Никакой подсчет не покажет структуру этих "разовых" комментаторов. Кто из них действительно разовый, а кому отбили охоту. Это как маркетологи исходят на какашки, добиваясь фидбеков от клиентов. Но один недовольный клиент из-за некачественного обслуживания поднимет вой на всех углах, а три других ни слова не скажут, просто в следующий раз обратятся в другое место. А вы сидите и думайте почему все эти клиенты оказался разовыми.
Намного более интересную статистику можно было бы нарыть в динамике измения состава и распределения по уровням у активных 37%. Вот тут можно было бы увидеть ведется ли активными пользователями игра в "царя горы" или просто жизнь такая неоднозначная штука :)
За спокойное, корректное и аргументированно выраженное мнение ничего страшного с кармой не происходит — даже если вы утверждаете, что Земля плоская. Но если упорно не слышать сообщество, добавлять в комментарии эмоции, переходы на личности, навешивать ярлыки и делать неуместные обобщения — да, запросто «прилетит». В том числе по этой причине первое нововведение даёт возможность голосовать только в плюс. Семь раз отмеряйте, прежде чем отрезать.
Много лет назад, под одной публикацией в програмистском разделе, где они хейтили что-то, связанное с какой-то БД, я написал один комментарий с точки зрения архитектуры БД, который шел в разрез с мнением стаи. Меня жестко заминусовали, потом мой комментарий поддержали другие знающие БД... но никто мне не кинул "+", потому что я не был из их стаи.
Карма на Хабре - это исключительно инструмент борьбы с чужаками не из твоей стаи и поддерживание своих, коллег по стае. И естественно, что чем тупее и агрессивнее индивидуум, тем активней он использует этот инструмент.
До этого я сделал одну статью на Хабре, и больше ничего не пишу. Жизнь слишком коротка для того, что бы бороться за место в какой-то виртуальной стае, которая может перестать существовать в любой момент времени по воле владельцев сайта.
Вот на днях проблемка возникла у бизнеса — есть некий документ, который оформляет пользователь системы, на печатной форме документа его ФИО стоит. Разработчики, создавшие систему изначально, не мудрствуя лукаво сделали в таблице документа поле user_id, ведь ФИО есть в таблице пользователей. Нормализация наше всё и т. п. Но не учли, что людям, особенно девушкам, свойственно иногда менять ФИО, а на печатных формах ФИО пользователя должно быть на момент, грубо говоря, создания документа.
Тут проблема не в SQL, а в ДНК того, кто проектировал workflow.
Если у объекта со временем может меняться какой-то атрибут (ФИО юзера в данном случае, а еще могут меняться паспортные данные, размер достоинств и т.д.), то надо завести отдельную таблицу и там хранить историю этих изменений. В случае очаговости таких явлений (не все юзеры женщины, не все женщины выходят замуж «после того как», не все вышедшие замуж меняют фамилию и т.д.) это будет намного выгоднее с точки зрения использования ресурсов, чем во всех документах жестко забивать в шапку этот реквизит. Особая прелесть вылезет когда выяснится, что атрибут объекта изменен «задним числом» или при изменении атрибута допущена ошибка. В случае таблицы с историей изменений редактируется только запись в ней, и не нужно бегать как умалишенному по всей БД в поисках этих ФИО, проверке их на необходимость исправления и собственно исправлении — обязательно что-то будет упущено.
И да: для особо критичных случаев можно по-прежнему жестко фиксировать в документе текущие значения атрибута. Но это должно быть исключением, а не правилом.
Да ну, какая шоколадка инспектору там где вообще не было учета и все было красиво? Это у вас профдеформация взрослым учетом.
СПД/ИП лепят что попало и никого ничего не волнует, лишь бы кассовый аппарат/безнал сошелся с отчетом (утрирую, есть наемные работники и т.п. но правильные счета возвратов это точно ерунда). А в цивилизованных странах у микробизнесов вообще все настолько пофиг что даже иногда шокирует.
Ну, по моим наблюдениям, у вас в последнее время делают все что угодно, только не облегчают жизнь микробизнесам. Поэтому необходимо быть готовым к закручиванию гаек.
То, что я за 4+ года налоговую ни разу не посетил и ни одного отчета вне общего графика не сдал не говорит ровно ни о чем — трахнут какого-то моего контрагента и пойдут трусить его контрагентов встречными проверками и штрафовать/сажать/штрафовать. А еще с вашими перекладками ответственности за определение добросовестности контрагентов на плечи бизнеса так вообще все весело становится…
Профдеформация у меня если и есть, то от другого, но в целом Вы правы — если информацию можно структурировать и сохранить, то ее обязательно надо структурировать и сохранить.
Ну так обороты то как раз становятся более правильными.
Примитивно != правильно.
Почему правильное чуть-чуть сложнее, написал ранее. Здесь Вы хотите облегчить свою работу, не особенно думая о завтрашнем дне. Имеете право — это Ваш продукт, — но истина дороже :)
Налог с продаж (американский вы имеете ввиду?) да, плясать будет плохо, хотя как я помню там он на бизнес бизнесу не распространяется.
В РФ его отменили в начале нулевых. В РФ его регулярно обсуждают с конца 2016. В РФ его скорее всего введут в 2019.
По каким правилам это будет работать в РФ — мне не известно. Но вряд ли по американским. :)
И опять же: разные операции подчинять одним и тем же правилам физического документооборота намного проще, чем «свалку» разделять по разным правилам на основании каких-то косвенных признаков.
А остальное можно учесть и так. Проводки то видны.
По своему опыту лоточной торговли в первой половине 90-ых знаю, что более-менее понимать чем выгодней торговать можно только при 2..3 поставщиках и не более 5...10 видов товаров. Дальше уже только нормальный учет или чутье (которое чаще подводит, чем нет).
А с кофе/молоком выходит как раз близко к «по ошибке провели». Поставщик дал на условиях покупки, т.е. мы у него купили, не взяли под реализацию и т.п., а именно купили, а потом (спустя пару недель, так что да, другой учетный период, в разрабатываемой системе учета учетный период неделя планируется) вдруг решил разорвать договор. Но поскольку расходники в значительной мере привязаны к конкретному поставщику и конкретной машинке, а разрыв по его вине то он забрал остатки расходников (кофе/молоко/шоколад), посчитав пропорционально расходу остаток и вернув деньги. Фактически тут мы купили, а потом через две недели оказалось что «ой, нет, не купили, отдавай мои какашки, забирай свои бумажки». Тут по смыслу явное сторно, т.е. отмена операции, только на другом уровне абстракции, не ошибка учета а «тот день когда я с тобой познакомился был ошибкой».
Тут нет никакой ошибки — банальный [частичный] возврат товара поставщику. И который должен идти в оборот между вами как контрагентами (в РФ так?).
Так же при подбитии управленческих итогов необходимо понимать, что «тут» продажа готового продукта (стаканчик кофе) и есть такая-то прибыль, а «там» возврат расходников поставщику и прибыли тут нет. А на следующем уровне анализа при подготовке среза «там» мы должны понимать с каким поставщиком и когда и по какой причине происходили возвраты — переоценка под акцию поставщика, возврат некондиции, выбрыки поставщика (описанный Вами случай) и т.д. Ведь как иначе понимать с кем стоит работать. а с кем нет?
Так же при наличии налога с продаж такое проведение возврата приведет к необходимости уплаты этого самого налога. Кому это нужно?
Для «учета для блондинок» все это можно спрятать под оберткой с каким-то подобием учета на регистрах, но внутри все должно быть ок.
Теоретически по бухучету это надо было бы проводить по другим счетам с другой корреспонденцией, но итог все равно был бы тот-же, и сальдо бы не поменялось.
Не теоретически, а практически так надо делать, иначе «шоколадка» фининспектору будет расти в геометрической прогрессии. Сальдо — это просто показатель текущего среза. Показатели оборота очень важны, а Вы хотите это отрезать.
Да что далеко ходить, тут у нас прямо на хабре куча людей не готова воспринять двойную запись, а тут куча малопонятных счетов с «более правильной» корреспонденцией. Нафиг, нафиг.
То что они что-то не могут воспринять — это пол-беды, страшнее, что они за это минусят направо и налево и в кармо. Агрессивное невежество ведет любое сообщество вниз и только вниз.
PS
Внимательно посмотрите на Gnucash — или придете к пониманию, что изобретаете велосипед, или сможете почерпнуть оттуда много полезного. В случае «велосипеда» может будет иметь смысл сосредоточиться на изготовлении обертки к Gnucash?
С другой стороны у меня тоже стойкое предубеждение против сторно в живой работе.
Но в реальной жизни без этого никак — отмену ошибочной (поспешной) реализации или ошибочного прихода (например: накладную поставщика по учету провели «по бырому», а живой товар до склада так и не дошел) в учетной системе надо именно сторнировать, так как фактически этих операций не было и в обороте с контрагентом они учитываться не должны. В отличие от кофемашины, которую поставщик поставил год назад, на которую в течение года шли затраты на расходники, электроэнергию, воду и т.д. Да еще и возврат может производиться с учетом амортизации.
Сторно — это коррекция ошибок. В данном же случае происходит возврат товара поставщику. Если продукт делается с прицелом на вырост, то лучще сразу все делать по-человечески.
Практически любой человек, который ездит за границу, вынужден думать о покупке/продаже валюты. Предлагаете вообще не ездить?
Мне тоже очень нравится творчество А. Макаревича, но применять буквально к реальной жизни его «Не стоит прогибаться под изменчивый мир» как-то не додумался :) Думаете стоит попробовать?
1. Мы будем искать и находить много новых вариантов. Последнее слово тут не скажет никто. :) Всего лишь поделился своими наблюдениями за имеющимися реализациями.
У меня есть пачка «обезьянок», которым базовую математику исчисления НДС привить не могу, но они очень сильно любят «красивые цифирьки» и крайне недовольны, когда не могут занести в систему подготовленный в Excel прайс-лист, красивость которого обеспечена использованием до 8 знаков после запятой. :(
2. Все зависит от конкретного законодательного поля данной страны. Корректирующие проводки налогового учета, например.
Я же обратил внимание на то, что автор «запрещает» показывать отрицательные цифры/итоги. Но что делать с отрицательными балансом или сальдо — он не сказал. Когда смотришь оборотно-сальдовую ведомость по клиенту, то проще все понять по знаку, чем оперировать дебитом/кредитом. А тем более когда просматриваешь пачку клиентов одной таблицей. Ну за исключением идеального случая, когда сразу ноль, конечно :)
3. buy/sell, bid/ask — суть одного поля термины, где традиции среды, в которой они используются, намного важнее программистского идеального мира.
Когда ГСМ или лаки-краски закупаются по весу, а реализуются по объему? В первом случае свои корректировки вносит температура товара, во втором точность отмеривания (40 кг бочку отпускают большим количеством порций с точностью до 10 мл). Обе эти задачи без регулярных инвентаризаций по нормативам решения практически не имеют.
А такие нюансы регулируются подзаконными актами. Прямого указания выписывать одну накладную на товары/услуги с разными ставками НДС я в вашем Налоговом кодексе не нашел. Как, впрочем, и запрет на выписку раздельных накладных.
С т а т ь я 153. Налоговая база
…
При применении налогоплательщиками при реализации товаров
(работ, услуг) различных налоговых ставок налоговая база
определяется отдельно по каждому виду товаров (работ, услуг),
облагаемых по разным ставкам. При применении одинаковых ставок
налога налоговая база определяется суммарно по всем видам операций,
облагаемых по этой ставке.
…
Я не понимаю за что заминусили Ваш пост выше любители «красивых счетов-фактур любой ценой», но в какой «помойке» законодательство позволяет (или даже настаивает?) считать НДС построчно и потом суммировать это? Такой подход противоречит самой сути данного налога.
1. Суммы округлять через round() перед каждой операцией — далеко не самый плохой приницп работы с ними.
1.1. Как вариант: хранить суммы в полях int в значениях наименьшой возможной единицы (копейки, центы) и делить их на степень кратности к денежной единице только перед выводом на экран/печать. Кстати, такие реализации встречал неоднократно.
2. Проводки, особенно корректирующие, могут быть и с отрицательным знаком, а не только дебетовые и кредитовые. Так что не надо путать работу с суммами и корректность отображения результатов в пользовательском интерфейсе. В конце концов баланс имеет право быть отрицательным, как и сальдо.
3. Покупка/продажа валюты, акций и т.д. во всем мире идет как bid/ask. Оператор рынка (банк в данном случае) объявялет обменные курсы, по которым покупает и продает. Если юзер не понимает таких элементарных вещей, то лучше ему не заниматься такими операциями. Какой велосипед изобретаете?
Если бы только в этом проблема была! В AXAPTA «не одобряется» использование более 2-х знаков после запятой, зато для 1сников 4...6 знаков для получения «красивых» сумм из-за НДС — почти норма.
И сколько «этим» не рассказывай, что при ставке НДС 20% и цене товара 100 грн с НДС (83,[3] грн без НДС) будут копеечки гулять, — они все равно проводят «округления» в 4...6 знаке и потом удивляются, что остальные такие тупые и так не делают.
offtop, но все-таки:
А как компилить эту DLL? Какие должны быть настройки проекта в VS2015, чтобы компилятор не ругался на недоступность namespace Sniffer?
Вот как в Facebook затыкают рты и почему надо дождаться полного запрета Meta на россии, после чего там можно будет относительно свободно общаться. Ниже написана полная правда - я получал баны за использование слова "вата" в контексте обычных сообщений с большей долей сарказма. И в постсоветском инете ботами больше всех балуется только одна страна - россия.
https://novayagazeta.ru/articles/2022/03/11/vash-instagram-za-lupoi-sledovatelia
Очередная ложь в духе соловьева и киселева. Пророссийская модерация в Facebook давит даже за слово "вата" как за призывы к насилию на национальной почве. Лично я с начала горячей фазы войны россии против Украины (фактически война началась 8 лет назад) туда ни ногой. Вот сейчас россия забанит у себя Мету, российские модераторы (точнее смотрители) отойдут от дел (переключатся на скрепный VK или еще что) и где-то к осени можно подумать о возвращении туда.
Никакой подсчет не покажет структуру этих "разовых" комментаторов. Кто из них действительно разовый, а кому отбили охоту. Это как маркетологи исходят на какашки, добиваясь фидбеков от клиентов. Но один недовольный клиент из-за некачественного обслуживания поднимет вой на всех углах, а три других ни слова не скажут, просто в следующий раз обратятся в другое место. А вы сидите и думайте почему все эти клиенты оказался разовыми.
Намного более интересную статистику можно было бы нарыть в динамике измения состава и распределения по уровням у активных 37%. Вот тут можно было бы увидеть ведется ли активными пользователями игра в "царя горы" или просто жизнь такая неоднозначная штука :)
Это если твоя карма позволяет ставить отметки в карму другим :) А так получается далеко не всегда :(
Много лет назад, под одной публикацией в програмистском разделе, где они хейтили что-то, связанное с какой-то БД, я написал один комментарий с точки зрения архитектуры БД, который шел в разрез с мнением стаи. Меня жестко заминусовали, потом мой комментарий поддержали другие знающие БД... но никто мне не кинул "+", потому что я не был из их стаи.
Карма на Хабре - это исключительно инструмент борьбы с чужаками не из твоей стаи и поддерживание своих, коллег по стае. И естественно, что чем тупее и агрессивнее индивидуум, тем активней он использует этот инструмент.
До этого я сделал одну статью на Хабре, и больше ничего не пишу. Жизнь слишком коротка для того, что бы бороться за место в какой-то виртуальной стае, которая может перестать существовать в любой момент времени по воле владельцев сайта.
Тут проблема не в SQL, а в ДНК того, кто проектировал workflow.
Если у объекта со временем может меняться какой-то атрибут (ФИО юзера в данном случае, а еще могут меняться паспортные данные, размер достоинств и т.д.), то надо завести отдельную таблицу и там хранить историю этих изменений. В случае очаговости таких явлений (не все юзеры женщины, не все женщины выходят замуж «после того как», не все вышедшие замуж меняют фамилию и т.д.) это будет намного выгоднее с точки зрения использования ресурсов, чем во всех документах жестко забивать в шапку этот реквизит. Особая прелесть вылезет когда выяснится, что атрибут объекта изменен «задним числом» или при изменении атрибута допущена ошибка. В случае таблицы с историей изменений редактируется только запись в ней, и не нужно бегать как умалишенному по всей БД в поисках этих ФИО, проверке их на необходимость исправления и собственно исправлении — обязательно что-то будет упущено.
И да: для особо критичных случаев можно по-прежнему жестко фиксировать в документе текущие значения атрибута. Но это должно быть исключением, а не правилом.
Ну, по моим наблюдениям, у вас в последнее время делают все что угодно, только не облегчают жизнь микробизнесам. Поэтому необходимо быть готовым к закручиванию гаек.
То, что я за 4+ года налоговую ни разу не посетил и ни одного отчета вне общего графика не сдал не говорит ровно ни о чем — трахнут какого-то моего контрагента и пойдут трусить его контрагентов встречными проверками и штрафовать/сажать/штрафовать. А еще с вашими перекладками ответственности за определение добросовестности контрагентов на плечи бизнеса так вообще все весело становится…
Профдеформация у меня если и есть, то от другого, но в целом Вы правы — если информацию можно структурировать и сохранить, то ее обязательно надо структурировать и сохранить.
Примитивно != правильно.
Почему правильное чуть-чуть сложнее, написал ранее. Здесь Вы хотите облегчить свою работу, не особенно думая о завтрашнем дне. Имеете право — это Ваш продукт, — но истина дороже :)
В РФ его отменили в начале нулевых. В РФ его регулярно обсуждают с конца 2016. В РФ его скорее всего введут в 2019.
По каким правилам это будет работать в РФ — мне не известно. Но вряд ли по американским. :)
И опять же: разные операции подчинять одним и тем же правилам физического документооборота намного проще, чем «свалку» разделять по разным правилам на основании каких-то косвенных признаков.
По своему опыту лоточной торговли в первой половине 90-ых знаю, что более-менее понимать чем выгодней торговать можно только при 2..3 поставщиках и не более 5...10 видов товаров. Дальше уже только нормальный учет или чутье (которое чаще подводит, чем нет).
Тут нет никакой ошибки — банальный [частичный] возврат товара поставщику. И который должен идти в оборот между вами как контрагентами (в РФ так?).
Так же при подбитии управленческих итогов необходимо понимать, что «тут» продажа готового продукта (стаканчик кофе) и есть такая-то прибыль, а «там» возврат расходников поставщику и прибыли тут нет. А на следующем уровне анализа при подготовке среза «там» мы должны понимать с каким поставщиком и когда и по какой причине происходили возвраты — переоценка под акцию поставщика, возврат некондиции, выбрыки поставщика (описанный Вами случай) и т.д. Ведь как иначе понимать с кем стоит работать. а с кем нет?
Так же при наличии налога с продаж такое проведение возврата приведет к необходимости уплаты этого самого налога. Кому это нужно?
Для «учета для блондинок» все это можно спрятать под оберткой с каким-то подобием учета на регистрах, но внутри все должно быть ок.
Не теоретически, а практически так надо делать, иначе «шоколадка» фининспектору будет расти в геометрической прогрессии. Сальдо — это просто показатель текущего среза. Показатели оборота очень важны, а Вы хотите это отрезать.
То что они что-то не могут воспринять — это пол-беды, страшнее, что они за это минусят направо и налево и в кармо. Агрессивное невежество ведет любое сообщество вниз и только вниз.
PS
Внимательно посмотрите на Gnucash — или придете к пониманию, что изобретаете велосипед, или сможете почерпнуть оттуда много полезного. В случае «велосипеда» может будет иметь смысл сосредоточиться на изготовлении обертки к Gnucash?
Но в реальной жизни без этого никак — отмену ошибочной (поспешной) реализации или ошибочного прихода (например: накладную поставщика по учету провели «по бырому», а живой товар до склада так и не дошел) в учетной системе надо именно сторнировать, так как фактически этих операций не было и в обороте с контрагентом они учитываться не должны. В отличие от кофемашины, которую поставщик поставил год назад, на которую в течение года шли затраты на расходники, электроэнергию, воду и т.д. Да еще и возврат может производиться с учетом амортизации.
Ну разве что для поржать :)
Мне тоже очень нравится творчество А. Макаревича, но применять буквально к реальной жизни его «Не стоит прогибаться под изменчивый мир» как-то не додумался :) Думаете стоит попробовать?
У меня есть пачка «обезьянок», которым базовую математику исчисления НДС привить не могу, но они очень сильно любят «красивые цифирьки» и крайне недовольны, когда не могут занести в систему подготовленный в Excel прайс-лист, красивость которого обеспечена использованием до 8 знаков после запятой. :(
2. Все зависит от конкретного законодательного поля данной страны. Корректирующие проводки налогового учета, например.
Я же обратил внимание на то, что автор «запрещает» показывать отрицательные цифры/итоги. Но что делать с отрицательными балансом или сальдо — он не сказал. Когда смотришь оборотно-сальдовую ведомость по клиенту, то проще все понять по знаку, чем оперировать дебитом/кредитом. А тем более когда просматриваешь пачку клиентов одной таблицей. Ну за исключением идеального случая, когда сразу ноль, конечно :)
3. buy/sell, bid/ask — суть одного поля термины, где традиции среды, в которой они используются, намного важнее программистского идеального мира.
Когда ГСМ или лаки-краски закупаются по весу, а реализуются по объему? В первом случае свои корректировки вносит температура товара, во втором точность отмеривания (40 кг бочку отпускают большим количеством порций с точностью до 10 мл). Обе эти задачи без регулярных инвентаризаций по нормативам решения практически не имеют.
И внимательно читайте второе выделение.
Налоговый кодекс
Тупое минусение извинению не подлежит.
Речь не об алгоритмах, а о требованиях закона. Товары с разными ставками НДС будьте добры отпускать разными расходными накладными.
1.1. Как вариант: хранить суммы в полях int в значениях наименьшой возможной единицы (копейки, центы) и делить их на степень кратности к денежной единице только перед выводом на экран/печать. Кстати, такие реализации встречал неоднократно.
2. Проводки, особенно корректирующие, могут быть и с отрицательным знаком, а не только дебетовые и кредитовые. Так что не надо путать работу с суммами и корректность отображения результатов в пользовательском интерфейсе. В конце концов баланс имеет право быть отрицательным, как и сальдо.
3. Покупка/продажа валюты, акций и т.д. во всем мире идет как bid/ask. Оператор рынка (банк в данном случае) объявялет обменные курсы, по которым покупает и продает. Если юзер не понимает таких элементарных вещей, то лучше ему не заниматься такими операциями. Какой велосипед изобретаете?
И сколько «этим» не рассказывай, что при ставке НДС 20% и цене товара 100 грн с НДС (83,[3] грн без НДС) будут копеечки гулять, — они все равно проводят «округления» в 4...6 знаке и потом удивляются, что остальные такие тупые и так не делают.
А как компилить эту DLL? Какие должны быть настройки проекта в VS2015, чтобы компилятор не ругался на недоступность namespace Sniffer?