neyara: В схеме cms -> агрегатор -> пробивка чека(ферма касс) -> cms агрегатор лишнее звено. Не все платежи проводятся через агрегатора. Более того, большая часть платежей как раз НЕ через агрегатора (курьеры/наложка/забрать в офисе итд). + цмс надо пилить под каждого агрегатора получается, у которого такая схема будет, а потом уже на ближайшее время 2 раза переделывать под новый формат чеков И зная наших кнопкодавов - такие переделки будут каждые 2-3 месяца (было где-то исследование, что у нас законы принимают на такой срок в среднем, а потом вносят правки, переделки итд)
Для платежей НЕ через агрегатора - курьеры, наложка, офис - в любом случае придётся вторую кассу держать. Интернет кассу же только для дистанционных заказов можно использовать.
Ну и опять таки - API и доступ к кассе в ферме будет отдельно от агрегатора, а значит никто не мешает его использовать и без агрегатора.
Смысл давать доступ к API кассы только в том, чтобы не получилось ситуации когда платеж "принят", а чек не отправился.
neyara: Всё бы хорошо, только есть одна существенная проблема
В чеке должны быть наименования товаров и скидки на них по каждой позиции и ставка ндс и ещё куча всего, а скоро будет обновление формата фискальных данных, а потом ещё одно.
Что-то не понимаю, а в чем технически проблема заставить CMS передавать агрегатору все эти данные? (Наименование, кол-во, цена, сумма, что там с НДС и т.п.), чтобы он по ним принял оплату и дальше сам передал эти данные на ферму касс ? Они же оказывают "информационно-техническое взаимодействие" - ну вот пусть более глубоко его оказывают, чем в данный момент. Понятно, что придётся пилить и CMS, и агрегатору свой софт, ну так а кому сейчас легко...
Схема получается cms -> агрегатор -> пробивка чека(ферма касс) -> cms. Т.е. между "агрегатор и ферма касс" нет лишних звеньев, которые могут выйти из строя. Ну и опять таки - CMSка в данной схеме мне кажется наиболее не надежным звеном, так как (1) расположена черт-знает-где (у меня например на VDSке) и (2) чаще всего криво-косо настроена.
Astrolog: По идее касса должна быть именно у агрегатора, чтобы исключать это слабое звено...
Мне кажется все придет к тому, что в яндекс.кассе и подобных можно просто будет тыкать "галочку", вводить "апи ключ" и агрегатор будет сам общаться по API с фермой касс. Наверное будут даже какие-то стандартные опции - типа подключить облако АТОЛ, облако СТАРРУС и т.п. Ну или подключить свою кассу - тогда мол выбрать тип кассы, указать ип, логин, пароль и т.п. Если конечно не предложат "мол работаете через нас - значит используйте нашу ферму касс". Не зря же они своё ОФД мутят.
neyara: Пока атол анонсировал свою ферму и под полой продавал кассы всяким адвантшопам и клодпейментам для перепродажи по 45к в год, некоторые более расторопные сделали аналогичное решение, только в 1,5 раза дешевле
http://starrys.ru/ecommerce.html И пишут что есть готовые модули для цмс
Так что если кто надумал ставить кассу, то можно и их рассмотреть. Всё же не 45к, а 30 в год
Хотелось бы отметить - "ККТ РП-Система 1 ФА", которую они предлагают, есть в реестре, но для торговли через автоматы. Даже у них на сайте http://asc.starrys.ru/catalog/kassovye_apparaty/ - эта модель отмечена для торговли через терминалы или автоматы. Для интернет магазинов должна быть касса ККТ РП-Система 1 ФC, но её я не вижу в данный момент в реестре ФНС от 30го марта ( тут https://www.nalog.ru/rn77/related_activities/registries/reestrkkt/ ). К слову - модель 1ФА в реестр добавили еще 8го февраля этого года, и странно, что еще не добавили 1 ФС.
Там в частности есть полезные ссылки - https://youtu.be/ifgyfAgyeH4?t=3560 --- тут например на вебинаре говорят, что ФНС присылала им ответ, что при ХОЛДе чек всё-таки выбивать надо, мол был ответ им официальный из ФНС.
Хотя вроде как минфин отвечал (правда со ссылкой на ЗоЗПП 92го года), что "С учетом изложенного при осуществлении расчета в сети Интернет электронными средствами платежа организация обязана применять ККТ с момента подтверждения исполнения распоряжения о переводе электронных средств платежа кредитной организацией." ( http://www.garant.ru/products/ipo/prime/doc/71539004/ ). Разве при холде есть распоряжение о переводе ?
Jaf4: Очень странно, что вы работаете с фото и такое советуете.
Я это советую с точки зрения лучшей цветопередачи, а не в качестве построения процесса серийной съёмки. И как я говорил, мы используем лампы накаливания для съемки, т.к. как вы сами заметили с ними проще создать контролируемые условия.
В прочем спасибо за "комплимент" - мы не профессиональные фотографы ни разу, просто фотографируем нашу продукцию.
Raffaell: у курьера ЧПУ, он вам выдаст бумажный чек. в чем проблема?
При регистрации ККТ присутствует такой параметр, как "адрес (при расчете в сети "Интернет" - адрес (адреса) сайта пользователя) и место установки (применения) контрольно-кассовой техники"
В обязательных реквизитах кассового чека присутствует "Адрес расчета."
Согласно 54-фз статьи 4.3 пункта 1 - "Контрольно-кассовая техника после ее регистрации в налоговом органе применяется на месте осуществления расчета с покупателем (клиентом) в момент осуществления расчета тем же лицом, которое осуществляет расчеты с покупателем (клиентом), за исключением расчета, осуществляемого электронными средствами платежа в сети "Интернет"
Согласно 54-ФЗ статьи 4.7 пункта 1 обязательный реквизит это - "дата, время и место (адрес) осуществления расчета (при расчете в зданиях и помещениях - адрес здания и помещения с почтовым индексом, при расчете в транспортных средствах - наименование и номер транспортного средства, адрес организации либо адрес регистрации индивидуального предпринимателя, при расчете в сети "Интернет" - адрес сайта пользователя);"
Согласно КоАП 14.5 пункт 4 (уже не буду цитировать) - за это штраф 1.5-3тыс.руб, для юриков 5-10тыс, или предупреждение.
Так что проблема всего-лишь в том, что данная схема (по моему мнению) не соответствует текущему законодательству, и влечёт на себя определенные риски.
У nextpay эта схема как реализована?
http://nextpay.ru/demo.php --- вот тут снизу слева "Банковские переводы" --- это и есть оно.
В схеме cms -> агрегатор -> пробивка чека(ферма касс) -> cms
агрегатор лишнее звено. Не все платежи проводятся через агрегатора. Более того, большая часть платежей как раз НЕ через агрегатора (курьеры/наложка/забрать в офисе итд).
+ цмс надо пилить под каждого агрегатора получается, у которого такая схема будет, а потом уже на ближайшее время 2 раза переделывать под новый формат чеков
И зная наших кнопкодавов - такие переделки будут каждые 2-3 месяца (было где-то исследование, что у нас законы принимают на такой срок в среднем, а потом вносят правки, переделки итд)
Для платежей НЕ через агрегатора - курьеры, наложка, офис - в любом случае придётся вторую кассу держать. Интернет кассу же только для дистанционных заказов можно использовать.
Ну и опять таки - API и доступ к кассе в ферме будет отдельно от агрегатора, а значит никто не мешает его использовать и без агрегатора.
Смысл давать доступ к API кассы только в том, чтобы не получилось ситуации когда платеж "принят", а чек не отправился.
Всё бы хорошо, только есть одна существенная проблема
В чеке должны быть наименования товаров и скидки на них по каждой позиции и ставка ндс и ещё куча всего, а скоро будет обновление формата фискальных данных, а потом ещё одно.
Что-то не понимаю, а в чем технически проблема заставить CMS передавать агрегатору все эти данные? (Наименование, кол-во, цена, сумма, что там с НДС и т.п.), чтобы он по ним принял оплату и дальше сам передал эти данные на ферму касс ? Они же оказывают "информационно-техническое взаимодействие" - ну вот пусть более глубоко его оказывают, чем в данный момент. Понятно, что придётся пилить и CMS, и агрегатору свой софт, ну так а кому сейчас легко...
Схема получается cms -> агрегатор -> пробивка чека(ферма касс) -> cms. Т.е. между "агрегатор и ферма касс" нет лишних звеньев, которые могут выйти из строя. Ну и опять таки - CMSка в данной схеме мне кажется наиболее не надежным звеном, так как (1) расположена черт-знает-где (у меня например на VDSке) и (2) чаще всего криво-косо настроена.
По идее касса должна быть именно у агрегатора, чтобы исключать это слабое звено...
Мне кажется все придет к тому, что в яндекс.кассе и подобных можно просто будет тыкать "галочку", вводить "апи ключ" и агрегатор будет сам общаться по API с фермой касс. Наверное будут даже какие-то стандартные опции - типа подключить облако АТОЛ, облако СТАРРУС и т.п. Ну или подключить свою кассу - тогда мол выбрать тип кассы, указать ип, логин, пароль и т.п. Если конечно не предложат "мол работаете через нас - значит используйте нашу ферму касс". Не зря же они своё ОФД мутят.
Давайте разберемся, что такое оплата картой?
В соседней теме уже все разобрали
Пока атол анонсировал свою ферму и под полой продавал кассы всяким адвантшопам и клодпейментам для перепродажи по 45к в год, некоторые более расторопные сделали аналогичное решение, только в 1,5 раза дешевле
http://starrys.ru/ecommerce.html
И пишут что есть готовые модули для цмс
Так что если кто надумал ставить кассу, то можно и их рассмотреть. Всё же не 45к, а 30 в год
Хотелось бы отметить - "ККТ РП-Система 1 ФА", которую они предлагают, есть в реестре, но для торговли через автоматы. Даже у них на сайте http://asc.starrys.ru/catalog/kassovye_apparaty/ - эта модель отмечена для торговли через терминалы или автоматы. Для интернет магазинов должна быть касса ККТ РП-Система 1 ФC, но её я не вижу в данный момент в реестре ФНС от 30го марта ( тут https://www.nalog.ru/rn77/related_activities/registries/reestrkkt/ ). К слову - модель 1ФА в реестр добавили еще 8го февраля этого года, и странно, что еще не добавили 1 ФС.
В копилочку - вот это предлагает PayAnyWay для соблюдения 54-ФЗ (модуль.кассу)
https://www.payanyway.ru/info/p/ru/public/merchants/PayAnyWay54FZ.pdf
http://bedrosova.blogspot.ru/2017/04/54-290.html неплохая статья от спеца по 1с битрикс.
Там в частности есть полезные ссылки - https://youtu.be/ifgyfAgyeH4?t=3560 --- тут например на вебинаре говорят, что ФНС присылала им ответ, что при ХОЛДе чек всё-таки выбивать надо, мол был ответ им официальный из ФНС.
Хотя вроде как минфин отвечал (правда со ссылкой на ЗоЗПП 92го года), что "С учетом изложенного при осуществлении расчета в сети Интернет электронными средствами платежа организация обязана применять ККТ с момента подтверждения исполнения распоряжения о переводе электронных средств платежа кредитной организацией." ( http://www.garant.ru/products/ipo/prime/doc/71539004/ ). Разве при холде есть распоряжение о переводе ?
Очень странно, что вы работаете с фото и такое советуете.
Я это советую с точки зрения лучшей цветопередачи, а не в качестве построения процесса серийной съёмки. И как я говорил, мы используем лампы накаливания для съемки, т.к. как вы сами заметили с ними проще создать контролируемые условия.
В прочем спасибо за "комплимент" - мы не профессиональные фотографы ни разу, просто фотографируем нашу продукцию.
у курьера ЧПУ, он вам выдаст бумажный чек. в чем проблема?
При регистрации ККТ присутствует такой параметр, как "адрес (при расчете в сети "Интернет" - адрес (адреса) сайта пользователя) и место установки (применения) контрольно-кассовой техники"
В обязательных реквизитах кассового чека присутствует "Адрес расчета."
Согласно 54-фз статьи 4.3 пункта 1 - "Контрольно-кассовая техника после ее регистрации в налоговом органе применяется на месте осуществления расчета с покупателем (клиентом) в момент осуществления расчета тем же лицом, которое осуществляет расчеты с покупателем (клиентом), за исключением расчета, осуществляемого электронными средствами платежа в сети "Интернет"
Согласно 54-ФЗ статьи 4.7 пункта 1 обязательный реквизит это - "дата, время и место (адрес) осуществления расчета (при расчете в зданиях и помещениях - адрес здания и помещения с почтовым индексом, при расчете в транспортных средствах - наименование и номер транспортного средства, адрес организации либо адрес регистрации индивидуального предпринимателя, при расчете в сети "Интернет" - адрес сайта пользователя);"
Согласно КоАП 14.5 пункт 4 (уже не буду цитировать) - за это штраф 1.5-3тыс.руб, для юриков 5-10тыс, или предупреждение.
Так что проблема всего-лишь в том, что данная схема (по моему мнению) не соответствует текущему законодательству, и влечёт на себя определенные риски.