Сдается мне, что сценарий будет такой:
— в платежах от ВебМани назначение платежа у вас будет что-то вроде «продажа ценных бумаг»
— налоговая спросит, откуда у вас эти ценные бумаги
— как только вы заикнетесь, что от третьих лиц, то они будут обложены налогом на те же 6%, плюс пени, плюс штраф
Вообще, для «белой» работы с ВебМани (как продавца) УСН по доходам или НДФЛ очень невыгодны, 6 или 13 процентов нужно платить как с входящих переводов, так и при выводе. А если ещё, например, конвертировать WMZ в WMR, то и при конвертации. В общем облагается практически любая операция, даже если на кошелке есть, скажем, 1000 WMR, 400 WMR вы платите за интернет, то должны заплатить налог с 600 WMR остатка, т. к. де-юре, вы передаете «Гарантийному агентству» или как там его ценную бумагу на 1000 р, оно платит оператору и передает вам новую ценную бумагу на 600 р. — ваш новый доход.
Если ВебМани рассматривается в качестве основного источника дохода, то выгодно выбирать УСН по доходам за вычетом расходов или ОСН. Если не основной, то или смириться с двойным налогообложением, или не работать абсолютно по-белому.
Далеко не всегда или не только в них. Например, если ты с каким-то модным перспективным пакетом/технологией/методикой не работал ещё и заказчик согласен подождать пока разберешься, то можно и меньше обычного своего рейта взять — дают обучиться на реальной задаче, да ещё деньги платят
Если «энтерпрайзные методологи» камень в мой огород, то, имхо, то что я предложил очень далеко от энтерпрайза, да и советы мои относились больше к организации процесса (я так понял вопрос), а не собственно к содержанию кода. К тому же задача, видимо, стоит не просто научиться писать на пхп, а сделать ASAP что-то на уже работающем бизнес-сайте, причем не своем, или своей фирмы, а заказчика фирмы, где Jakeroid работает. Учиться на своих ошибках может дорого встать и этой фирме, и самому Jakeroid'у. Пускай лучше учится на моих :) К тому же не поленился глянуть профиль и, вроде, не только программировать начинает ;) Ничего сложного для человека, который понимает разницу между номером элемента в массиве и его смещением :), в предложенных мною «методологиях» нет — выучить несколько консольных команд или освоить соответствующие средства в ИДЕ.
2knekrasov: эксепшен в таком случае можно вывалить самому, а вот если неявное преобразование устраивает, то придётся его ловить, что, имхо, сильнее испачкает код, чем самостоятельная его генерация.
Во, спасибо! Оказалось то, что нужно. Теоретический скрипт для хрона (пока делаю его ручками) или команды для PuTTY состоит из: cd /home/mirrorer/-hg
hg pull
hg push
Проверить что метод выдал корректный SQL с помощью моков и/или стабов у вас не получится. Если стоит задача проверки, что User::create() генерирует «INSERT INTO `users` ...» (а вернее, вызывает соответствующие методы PDO — ему же мы доверяем, что он корректно сгенерирует SQL?), то мокапьте $this->pdo, проверяя параметры, передаваемые в prepare() и execute(), чтобы они получали «INSERT INTO `users` ...» и $params соответственно.
Если же стоит задача проверять, что User::create() корректно пишет в БД, то это не юнит-тест уже получается, а интеграционный, проверяющий, что несколько подсистем приложения (ваш код, код pdo и код MySQL) вместе работают нормально и моки/стабы здесь не уместны.
P.S. А вообще работу с БД я бы вынес на отдельный уровень, в том числе и для облегчения тестирования. Конечно, если у вас не простое CRUD приложения и в классе User пристуствует не только работа с БД, а в других классах нет таких же функций create() с только $this->pdo->prepare() и $this->pdo->execute(), различающимися лишь именами таблиц и полей в INSERT.
Логику (бизнес-логику, а также «логику хранения») можно и не размазывать, а перенести её в СУБД полностью. Хотя поддерживать всё равно сложнее, из-за необходимости синхронизировать исходники процедур (файлы) и их «представление» в БД. Различные миграции и деплой-скрипты не убирают проблему полностью.
Вот не понимаю этого «немного не выгодно». Я, как поставщик на УСН, продаю магазину товар за 100 рублей. Он делает накрутку 100 рублей и НДС 18% — ценник для покупателя 236 рубл, 36 должен в бюджет, 100 мне, 100 его прибыль. Другой поставщик продает с НДС — 118 рублей. Магазин ставит те же 236 рублей для покупателя из них — 118 платит поставщику 36 в бюджет, 100 себе, но плюс получает 18 рублей из бюджета из уплаченных им 118 поставщику (по сути просто платит 18, а не 36) и получает те же 100 р прибыли. Где «невыгодно»? Только заморочек больше с возвратом.
Ну так ватермарки вашу проблему и решают. Или роетесь в дровах и ищете там что-то типа подстановок, или каждому юзеру засылаете его личный ватермарк, хоть картинкой. Другой вопрос как сделать, чтобы тексты не накладывались.
Даже с тем, что sf1.x копипаст RoR2.x не согласен полностью. Многое взято оттуда (или из одного источника? :) ), но не всё взято и не всё оттуда. Что многое в 2 из мира Java — согласен. Как и с тем, что в 2 наплевали на амбиции или, говоря по простому, не изобретали велосипед (но тренд ещё с 1 шёл).
P.S. А вот то, что многое из Java меня как-то ориентирует на то, что sf2 больше рассчитан на enterprise, чем на стартапы. Или на создание тиражируемых решений. Субъективно увеличилось количество предварительной работы за счёт уменьшения количества работы над поддержкой. Ещё не понял, хорошо это или плохо :)
— в платежах от ВебМани назначение платежа у вас будет что-то вроде «продажа ценных бумаг»
— налоговая спросит, откуда у вас эти ценные бумаги
— как только вы заикнетесь, что от третьих лиц, то они будут обложены налогом на те же 6%, плюс пени, плюс штраф
Вообще, для «белой» работы с ВебМани (как продавца) УСН по доходам или НДФЛ очень невыгодны, 6 или 13 процентов нужно платить как с входящих переводов, так и при выводе. А если ещё, например, конвертировать WMZ в WMR, то и при конвертации. В общем облагается практически любая операция, даже если на кошелке есть, скажем, 1000 WMR, 400 WMR вы платите за интернет, то должны заплатить налог с 600 WMR остатка, т. к. де-юре, вы передаете «Гарантийному агентству» или как там его ценную бумагу на 1000 р, оно платит оператору и передает вам новую ценную бумагу на 600 р. — ваш новый доход.
Если ВебМани рассматривается в качестве основного источника дохода, то выгодно выбирать УСН по доходам за вычетом расходов или ОСН. Если не основной, то или смириться с двойным налогообложением, или не работать абсолютно по-белому.