Согласен, хотя подозреваю, что тут страшность только в неизвестности, поскольку никто еще так не делает, и никто не хочет ставить опыты на себе. В теории такая ситуация обрабатывается легко, получил денег, выписал чек на ту сумму, которую получил. Получил вторую часть, выписал еще чек. Меняется в сравнении с обычным только тип операции, если не ошибаюсь.
Куда более веселая ситуация возникает при предоплате, если вторую часть денег магазин получает не напрямую от покупателя. Например, я оформил заказ с предоплатой, внес 30%, магазин сделал чек. При этом доставку я выбрал самовывозом СДЭК, и оставшуюся часть денег я заплачу в ПВЗ СДЭК-а. Вопрос — что в этой ситуации должен делать магазин? Я вот не знаю. И никто, кого я спрашивал, не знает. И СДЭК тоже не знает. :)
Интеграция через драйвер означает, что для интеграции ККМ с сайтом надо этот самый драйвер написать. Причем под десктоп. Разработчики сайтов, как правило, не специализируются на десктоп-разработке. Инхаус разработчиков у небольших инет-магазинов нет, ни десктопных, ни веб. Как дальше жить? :)
И нет, я не согласен, что это нормально, поскольку отсутствие единого стандарта приведет либо к костылизации драйвера и сайта магазина с размытыми последствиями (а баги в этом вопросе чреваты жертвами), и почти наверняка — к жесткой привязке несчастного магазина к определенной ККМ, драйверу под нее и сайту, поддерживающему обмен с этим драйвером. Этот вариант, кстати, активно продвигает в жизнь один из Ваших конкурентов с названием на «А», задружившийся с известной cms с названием на «Б». ;)
Насчет технических решений, некоторое время назад я попинал с вопросом «как предлагаете интегрироваться» упомянутых конкурентов на «А», и вторых крупных и известных тоже. В обоих случаях ответ был «ждите, пока ничего не готово, но скоро будет». Т.е. формально решения есть, но пощупать их и начать что-то делать нельзя. Если у Вас ситуация вдруг лучше, готов пообщаться подробнее и предметно.
По поводу самого закона, для небольших интернет-магазинов эти изменения — кошмар. На рынке все еще нет ни аппаратов, готовых к интеграции с сайтами, ни софта под это дело. Крупные игроки, производящие ККМ, радостно потирают руки и наживаются, как могут, типа организации «облачных касс» за неприличные деньги. При этом, для ККМ нет нормального API, чтобы можно было быстро организовать обмен данными с сайтами, есть только драйвера. И крутись, как хочешь — хочешь, пиши софт под десктоп, который организует общение кассы и сайта, хочешь, ищи обходные схемы и прячь свои продажи вообще, хочешь, плати суровые деньги за переделку и доработку сайта. Весело, да.
Нет, как разработчик, я не возражаю, чтобы мне платили деньги. Однако отсутствие вменяемых технических решений как минимум раздражает. Приходится изобретать очередной велосипед, который неизвестно, сколько проедет, не развалившись, т.к. требования к софту ККМ с момента принятия закона уже прошли несколько редакций, и не факт, что достигли финальной точки. А несчастные владельцы маленьких интернет-магазинов рвут волосы на всех местах, поскольку платить за каждое изменение придется именно им.
Не менее веселый момент для покупателей, при покупке на сайте с оплатой через интернет теперь бумажный чек вообще не предусмотрен. И вот вопрос, а все ли сервис-центры в курсе, что бумажный чек им могут не показать? Ничто им не мешает просто сказать: «Нет накладной и чека — до свидания. А мобильником своим с почтой под нос нам тыкать не надо, бумажку неси». И можешь спорить до хрипоты, тратя нервы. Актуально в первую очередь для случаев, когда сервис-центр не магазина, а производителя. И пока этот момент не прояснится, технику покупать буду только так, чтобы получить бумажный чек. Кстати, кто не знает, электронный чек внешне не идентичен бумажному, выглядит примерно так — http://docplayer.ru/docs-images/53/31839280/images/8-0.jpg
Управляю разработкой почти 8 лет как CTO, немного программист, имеют опыт около 5 лет как фронтенд-разработчик.
И именно поэтому проблем, сходных с описываемыми в посте, у меня не возникает — я говорю с менеджерами на их языке, с разработчиками — на их. Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит. Он обещает клиенту золотые горы, и уже завтра, он не понимает, что «добавить галочку» одновременно значит «перелопатить логику в десятке мест и все протестировать», он хочет, чтобы конкретно его клиенту сделали ту фичу, которую этот клиент хочет прямо сейчас, бросив все другие дела.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру» — расставить приоритеты, превратить поток сознания менеджера-продажника в нормальные задачи, решить, кто эти задачи сделает эффективнее и распределить их, оценить сроки (когда самому, а когда и посоветовавшись), проконтролировать исполнение, а также заблокировать неумеренный и неуместный энтузиазм вида «да это буквально 5 минут, давайте сделаем прям щас». Ага, щас, разбежались.
Вообще стараюсь не допускать прямого контакта технарей и менеджеров, если честно. Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды. И это облегчает жизнь всем этим частям.
Думаю, без такого контроля, когда все, что подается на вход в разработку извне, разбирается человеком, понимающим техническую часть, полу-менеджером и полу-технарем, любая методология может фейлиться, как и описано в посте. Скрам, ватерфол — итог один, завал разработчиков «текучкой», раздрай в команде и полное непонимание менеджерами, почему у них все не так, как хочется. И чем больше команда, тем больше будет проблем.
Куда более веселая ситуация возникает при предоплате, если вторую часть денег магазин получает не напрямую от покупателя. Например, я оформил заказ с предоплатой, внес 30%, магазин сделал чек. При этом доставку я выбрал самовывозом СДЭК, и оставшуюся часть денег я заплачу в ПВЗ СДЭК-а. Вопрос — что в этой ситуации должен делать магазин? Я вот не знаю. И никто, кого я спрашивал, не знает. И СДЭК тоже не знает. :)
И нет, я не согласен, что это нормально, поскольку отсутствие единого стандарта приведет либо к костылизации драйвера и сайта магазина с размытыми последствиями (а баги в этом вопросе чреваты жертвами), и почти наверняка — к жесткой привязке несчастного магазина к определенной ККМ, драйверу под нее и сайту, поддерживающему обмен с этим драйвером. Этот вариант, кстати, активно продвигает в жизнь один из Ваших конкурентов с названием на «А», задружившийся с известной cms с названием на «Б». ;)
Насчет технических решений, некоторое время назад я попинал с вопросом «как предлагаете интегрироваться» упомянутых конкурентов на «А», и вторых крупных и известных тоже. В обоих случаях ответ был «ждите, пока ничего не готово, но скоро будет». Т.е. формально решения есть, но пощупать их и начать что-то делать нельзя. Если у Вас ситуация вдруг лучше, готов пообщаться подробнее и предметно.
По поводу самого закона, для небольших интернет-магазинов эти изменения — кошмар. На рынке все еще нет ни аппаратов, готовых к интеграции с сайтами, ни софта под это дело. Крупные игроки, производящие ККМ, радостно потирают руки и наживаются, как могут, типа организации «облачных касс» за неприличные деньги. При этом, для ККМ нет нормального API, чтобы можно было быстро организовать обмен данными с сайтами, есть только драйвера. И крутись, как хочешь — хочешь, пиши софт под десктоп, который организует общение кассы и сайта, хочешь, ищи обходные схемы и прячь свои продажи вообще, хочешь, плати суровые деньги за переделку и доработку сайта. Весело, да.
Нет, как разработчик, я не возражаю, чтобы мне платили деньги. Однако отсутствие вменяемых технических решений как минимум раздражает. Приходится изобретать очередной велосипед, который неизвестно, сколько проедет, не развалившись, т.к. требования к софту ККМ с момента принятия закона уже прошли несколько редакций, и не факт, что достигли финальной точки. А несчастные владельцы маленьких интернет-магазинов рвут волосы на всех местах, поскольку платить за каждое изменение придется именно им.
Не менее веселый момент для покупателей, при покупке на сайте с оплатой через интернет теперь бумажный чек вообще не предусмотрен. И вот вопрос, а все ли сервис-центры в курсе, что бумажный чек им могут не показать? Ничто им не мешает просто сказать: «Нет накладной и чека — до свидания. А мобильником своим с почтой под нос нам тыкать не надо, бумажку неси». И можешь спорить до хрипоты, тратя нервы. Актуально в первую очередь для случаев, когда сервис-центр не магазина, а производителя. И пока этот момент не прояснится, технику покупать буду только так, чтобы получить бумажный чек. Кстати, кто не знает, электронный чек внешне не идентичен бумажному, выглядит примерно так — http://docplayer.ru/docs-images/53/31839280/images/8-0.jpg
И именно поэтому проблем, сходных с описываемыми в посте, у меня не возникает — я говорю с менеджерами на их языке, с разработчиками — на их. Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит. Он обещает клиенту золотые горы, и уже завтра, он не понимает, что «добавить галочку» одновременно значит «перелопатить логику в десятке мест и все протестировать», он хочет, чтобы конкретно его клиенту сделали ту фичу, которую этот клиент хочет прямо сейчас, бросив все другие дела.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру» — расставить приоритеты, превратить поток сознания менеджера-продажника в нормальные задачи, решить, кто эти задачи сделает эффективнее и распределить их, оценить сроки (когда самому, а когда и посоветовавшись), проконтролировать исполнение, а также заблокировать неумеренный и неуместный энтузиазм вида «да это буквально 5 минут, давайте сделаем прям щас». Ага, щас, разбежались.
Вообще стараюсь не допускать прямого контакта технарей и менеджеров, если честно. Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды. И это облегчает жизнь всем этим частям.
Думаю, без такого контроля, когда все, что подается на вход в разработку извне, разбирается человеком, понимающим техническую часть, полу-менеджером и полу-технарем, любая методология может фейлиться, как и описано в посте. Скрам, ватерфол — итог один, завал разработчиков «текучкой», раздрай в команде и полное непонимание менеджерами, почему у них все не так, как хочется. И чем больше команда, тем больше будет проблем.