Jump to content
Калькуляторы

54-ФЗ, онлайн касса, фискальный чек и что с этим делать... пипец подкрался незаметно...

А причем тут ЗоС? Тут речь за 54-ФЗ, деньги и налоги.

Дело не в деньгах, мы сейчас на чековые ленты тратим столько же, сколько бы тратили на SMS.

Но я не вижу причины, которая бы обязывала меня использовать именно SMS для отправки чека.

Инспектор или проверяющий может фантазировать по поводу термина «абонентский номер» сколько угодно, у меня фантазия будет побогаче.

Share this post


Link to post
Share on other sites
14 минут назад, alibek сказал:

Инспектор или проверяющий может фантазировать по поводу термина «абонентский номер» сколько угодно, у меня фантазия будет побогаче.

У инспектора методичка, разбираться будет уже суд, и 100% сошлются на ЗоС

Share this post


Link to post
Share on other sites
В 31.01.2019 в 13:09, alibek сказал:

Возможно.

Почему-то в интернете подобных решений очень мало.

Я только три нашел - EKAM, CloudKassir и АТОЛ.
Но АТОЛ по-моему не подойдет.

Вроде ещё можно использовать онлайн-кассу Ф от Дримкас, сами такой вариант рассматривали: из билинга загружать платежи по API в эту кассу.

Share this post


Link to post
Share on other sites
On 2/14/2019 at 3:55 PM, AlexTN said:

http://integration.atol.ru/#c850ebec42

Любая касса АТОЛ.

 

Здесь достаточно серьезный уровень интеграции. Низкоуровневый пласт языков. Нужно заморачиваться с открытием и закрытием смены, например. Очень понравился метод, вызываемый для отрезки ленты)). Вроде как даже 1С не использует этот драйвер напрямую, а только какую то часть и то через упрощенную прослойку. Это как писать echo "на ассемблере". А еще самое сложное все это поддерживать, ведь нпа меняются, добавляются новые реквизиты и капризы регулятора. Одно небольшое нововведение может заставить перевернуть все парадигму написанного собственного по для этих целей. Поэтому и развелось много Kaas. Суть проста, вместо полного контроля над кассовой машиной - отдаете по api примитивные команды с данными, типа сумма, номер телефона, фио кассира и т. д., а все остальное сервис сделает сам.

Если принимаете на сайте, то практически все системы и терминалы - это агенты и обязаны бить чеки, а письмо минфина позволяет продавцу не пробивать чек повторно в таком случае. Для этого предусмотрены специальные поля в чеке. Т.е. если они агенты они в любом случае чеки делают, просто кто то это монетизирует, а кто то нет.

 

Если кому интересно, я здесь напишу инфу от первых лиц налоговой областной (пусть и не в тему, но делится ка-кто нужно инфой):

 

1. Платежи на р/сч от физиков при усн бить с июля 2018г. - 100% (если у кого то другое мнение и типа от налоговиков, то мне тоже разные "девочки из налоговой - должностные лица по этому направлению" - говорили разное и в разное время их ответы были разные).

2. Одну кассу для платежей в интенет и р/сч использовать не запрещается, причем технически это возможно, но проблема в передаче постоянного параметра места расчетов в чеке, который статичен и указывается при регистрации кассы, т.е. если поступать таким способом какая то категория чеков будет попадать под нарушение, например при поступлении на р/сч в месте расчетов будет указан https://nag.ru. (т.е. параметр для расчетов в сети интернет - юридически значит "ТОЛЬКО ДЛЯ РАСЧЕТОВ В ИНТЕРНЕТ").

3. Одну ссылку на чек нельзя присылать, можно только ей дополнить текстовую информацию в смс - ФД, ФП, № ККМ и т.д. (хотя вроде как РТ просто ссылку присылает)

 

Если кому интересно как у меня реализовано (НЕ РЕКЛАМА)..

 

1. Касса АТОЛ 30 Ф + ФН36 + Raspberry + сервис КОМТЕТ Касса. Выбрал так как самый дешевый - 480 руб в месяц.

2. При платежах на сайте платежная система все делает.

3. При платежах через админку биллинга, т.е. при поступлениях на р/сч - скриптом заноситься в табличку базы вся инфа.

4. Раз в минуту отправляется на фискализацию по api - там библиотеки есть на Питон и ПХП.

5. Через минуту обновляются статусы и если все ок, то отправляем смс - со ссылкой на чек. Ссылку подставляю вида https://lk.platformaofd.ru/web/noauth/cheque?fn=00000000000000000fp=00000i=000. Данные вместо нулей беру из статуса чека.

 

https://github.com/Komtet/komtet-kassa-php-sdk

https://kassa.komtet.ru/integration/api

 

Так то нет никаких проблем, есть только непонятные моменты, которые уже рассеиваются и становится все ясным. Явным то, что это нужно делать - камеральная проверка после мая месяца нам скажет все.

Share this post


Link to post
Share on other sites
39 минут назад, pandatelecom сказал:

самое сложное все это поддерживать

Именно. Все это рукоблудие с собиранием на коленке можно сделать один раз на энтузиазме, но не как часть бизнес-процессов.

 

41 минуту назад, pandatelecom сказал:

Касса АТОЛ 30 Ф + ФН36 + Raspberry + сервис КОМТЕТ Касса. Выбрал так как самый дешевый - 480 руб в месяц.

Жаль что раньше не написали, я уже три года E-COM оплатил.

Share this post


Link to post
Share on other sites
4 часа назад, pandatelecom сказал:

какая то категория чеков будет попадать под нарушение

а как оформляются кассовые терминалы, с которыми курьеры пиццу развозят?

 

 

4 часа назад, pandatelecom сказал:

Нужно заморачиваться с открытием и закрытием смены, например.

С закрытием можно не заморачиваться.  Спустя 24 часа смена закрывается автоматически.

А насчет открытия -- да, это просто ужас.  В код обработки ошибок вставить, что если ФН возвращает ошибку "смена не открыта" , то направить в ФН команду "Открыть смену".

Это одна строчка кода, это умереть не встать, это чистый ассемблер и хардкор сразу.

 

 

4 часа назад, pandatelecom сказал:

Суть проста, вместо полного контроля над кассовой машиной - отдаете по api примитивные команды с данными, типа сумма, номер телефона, фио кассира и т. д., а все остальное сервис сделает сам.

Этот сервис и есть фискальный накопитель.  Вы именно в него и даете примитивную команду с данными типа сумма, номер телефона, id кассира ( список фамилий настраивается предварительно )  , а всё остальное фискальный накопитель делает сам.

Что касается ситуации с "изменятся НПА , изменятся запросы API , нам придется код переписывать "  - есть такой момент.  Но скорее всего, если НПА изменятся таким образом что производители фискальников будут вынуждены поломать совместимость драйвера ,  то и поставщикам облачных решений, скорее всего в своем API тоже придется ее сломать.  Шансы на то что какой-нить ШТРИХ не найдет  как выкрутиться, а облачники найдут - слабый.

 

Share this post


Link to post
Share on other sites
3 часа назад, alibek сказал:

Все это рукоблудие с собиранием на коленке можно сделать один раз на энтузиазме, но не как часть бизнес-процессов.

Это очень оторванные от жизни и практики рассуждения.

 

У вас биллинг есть?  Значит человек , который им занимается есть?

Изменения он какие то периодически вносит?

Ну значит и пару команд по отправки платежа на фискальник без проблем добавит и актуализирует при необходимости.

 

Вот если у вас и биллинг целиком в облаке, тогда да, надо облачную кассу подключать.

 

 

Share this post


Link to post
Share on other sites
2 minutes ago, LostSoul said:

Это очень оторванные от жизни и практики рассуждения.

 

У вас биллинг есть?  Значит человек , который им занимается есть?

Изменения он какие то периодически вносит?

Ну значит и пару команд по отправки платежа на фискальник без проблем добавит и актуализирует при необходимости.

 

Вот если у вас и биллинг целиком в облаке, тогда да, надо облачную кассу подключать.

 

 

Вы в чем то правы, а в чем то и нет. Речь идет об использовании драйвера АТОЛ напрямую без Kaas. В этом то и суть - в использовании онлайн сервиса - то, что поддержка более легкой будет, максимум добавится что то, или метод запроса изменится например. Но драйвер предполагает полный контроль над ккт. Тут таки как раз и надо и открыть и закрыть смены, учесть нужный период. При использовании его там ничего не закроется.. Это все делает сервис, он работает с учетом актуальных нововведений и требований с этим драйвером, а с другой стороны предполагает упрощенный вариант взаимодействия с пользователем ккт по web (https запросы). По сути библиотеки в конечном итоге и отправляют все на сервер в облаке таким путем, по https.

 

Команды то можно отправить. Речь идет о поддержке, масштабировании и соблюдении законодательства.. Например приведу, в каком случае было бы сделать легче - используя онлайн сервис с его API или напрямую используя драйвер, т.е. без использования сервиса Kaas случай внедрить исполнение новой версии ФФД 1.05??

 

В первом случае нужно платить за это, а во втором поддерживать самому, что кажется дороже..

 

 

17 minutes ago, LostSoul said:

а как оформляются кассовые терминалы, с которыми курьеры пиццу развозят?

 

 

С закрытием можно не заморачиваться.  Спустя 24 часа смена закрывается автоматически.

А насчет открытия -- да, это просто ужас.  В код обработки ошибок вставить, что если ФН возвращает ошибку "смена не открыта" , то направить в ФН команду "Открыть смену".

Это одна строчка кода, это умереть не встать, это чистый ассемблер и хардкор сразу.

 

 

Этот сервис и есть фискальный накопитель.  Вы именно в него и даете примитивную команду с данными типа сумма, номер телефона, id кассира ( список фамилий настраивается предварительно )  , а всё остальное фискальный накопитель делает сам.

Что касается ситуации с "изменятся НПА , изменятся запросы API , нам придется код переписывать "  - есть такой момент.  Но скорее всего, если НПА изменятся таким образом что производители фискальников будут вынуждены поломать совместимость драйвера ,  то и поставщикам облачных решений, скорее всего в своем API тоже придется ее сломать.  Шансы на то что какой-нить ШТРИХ не найдет  как выкрутиться, а облачники найдут - слабый.

 

 

Насчет курьеров вроде развозная торговля - но могу ошибаться и там место расчетов может быть даже номер авто указан - этот момент самый раскрытый в сети и там много практических решений и примеров.

 

Опять же без онлайн сервиса не закроется ничего, закроет только прослойка (Kaas) между пользователем и ККМ, использую этот драйвер.

 

Сервисы все насколько я знаю предполагают покупку ФН, так как это требования закона, просто его вставят в свою кассу (причем этот ФН теперь только с этой кассой только будет работать) и разместят у себя, некоторый предлагают купить все и разместить у пользователя. изменятся НПА.... В том то и дело изменится и АПИ, а в случае с драйвером посложнее все будет.. но можно. Ребята, связанные с кодингом поймут.  Я сейчас не топлю за покупку этих сервисов, самого бесит эта телега в коробке два зарядника, микрокомпьютер и касса - такой колхоз.. просто самый дешевый вариант таков был на тот момент.

Share this post


Link to post
Share on other sites
14 минут назад, pandatelecom сказал:

Тут таки как раз и надо и открыть и закрыть смены, учесть нужный период.

я повторюсь, закрытие смены через 24 часа фискальный накопитель произведет принудительно , если этого не сделать самим.

Это заложено в прошивку и не выключается.

 

 

14 минут назад, pandatelecom сказал:

Команды то можно отправить. Речь идет о поддержке, масштабировании и соблюдении законодательства.. Например приведу, в каком случае было бы сделать легче - используя онлайн сервис с его API или напрямую используя драйвер, т.е. без использования сервиса Kaas случай внедрить исполнение новой версии ФФД 1.05??

Я нигде не нашел информации о том, что данное обновление требует что-то менять в запросах, отправляемых в драйвер ФН.

написано - просто поставьте обновление прошивки на ФН ,  поменяйте протокол взаимодействия с ОФД в настройках, сделайте отчёт.

Что то ещё нужно?

 

 

14 минут назад, pandatelecom сказал:

просто самый дешевый вариант таков был на тот момент.

ну так вот можно и самому подключить Rapsberri PI к ФН 4 проводами , а не покупать у кого-то.

В конце концов, возможно что и в вашу платную облачную прокладку такое включить можно.

 

Хотя мне кажется более логичным , если обслуживать взаимодействие с ФН будет лицо, занимающееся обслуживанием биллинга.

 

Share this post


Link to post
Share on other sites
41 минуту назад, LostSoul сказал:

У вас биллинг есть?  Значит человек , который им занимается есть?

Изменения он какие то периодически вносит?

Странные рассуждения.

Биллинг есть, есть люди, которые с ним работают.

Если под "занимается" подразумевается "изменяет программный код", то такого нет.

Зачем такое нужно, да еще и периодически?

Share this post


Link to post
Share on other sites
3 минуты назад, alibek сказал:

Странные рассуждения.

Биллинг есть, есть люди, которые с ним работают.

Если под "занимается" подразумевается "изменяет программный код", то такого нет.

Зачем такое нужно, да еще и периодически?

Новую акцию какую-нибудь внедрить.

Тариф с новой методологией.

изменить / добавить новые модели и права доступа в связи с ростом бизнеса и появлением нового разделения обязанностей

да мало ли что

 

Share this post


Link to post
Share on other sites

А причем тут программный код биллинга?

Тарифы, акции и прочее настраивается в самом биллинге, как атрибуты тарифов, групп и прочего.

Или вы хардкодите все это в своем биллинге?

Share this post


Link to post
Share on other sites
9 минут назад, alibek сказал:

А причем тут программный код биллинга?

Тарифы, акции и прочее настраивается в самом биллинге, как атрибуты тарифов, групп и прочего.

ну это зависит от гибкости имеющегося модуля тарификации и фантазии маркетологов

Какие-нибудь там возможности "турбо-кнопок на час"  у вас уже есть из коробки?

 

Share this post


Link to post
Share on other sites

Турбо-кнопки на час по нынешним временам это глупость.

Тем не менее они есть из коробки и одно время мы пытались их применять, но отказались.

В биллинге нет плавающего расчетного периода — когда расчетной датой считается не 1-ое число или день подключения, а дата пополнения лицевого счета.

Но мы решили, что в этом случае лучше поумерить фантазии маркетологов, чем влезать в потроха биллинга, отвечающие за расчет абонплаты.

И я вообще не вижу причин, зачем нужно периодически его трогать.

Мы несколько раз вносили изменения в программный код, но каждый раз для этого была важная причина и это в любом случае делалось не от скуки, а после тщательного изучения и согласования изменений с разработчиком.

Share this post


Link to post
Share on other sites
2 часа назад, alibek сказал:

Турбо-кнопки на час по нынешним временам это глупость.

Тем не менее они есть из коробки и одно время мы пытались их применять, но отказались.

По большей части , Алибек , я разделяю ваши взгляды.

Однако-ж молодые хипстеры бывает обходят на поворотах.

Поэтому приходится и старым котам иногда учить новые фокусы.

 

Share this post


Link to post
Share on other sites
В 30.08.2018 в 12:20, ПС Центральная касса сказал:

Примеры чеков направила в лс

Так что там с этим сервисом? Катит для налоговой их фискализация по агентскому договору? Мб кто то из присутствующих использует, поделитесь впечатлениями?

Share this post


Link to post
Share on other sites
26 минут назад, Fint сказал:

Так что там с этим сервисом? Катит для налоговой их фискализация по агентскому договору? Мб кто то из присутствующих использует, поделитесь впечатлениями?

Там в соседней ветке новый мужчина от Центральной кассы появился. Он же статью в ленту нага написал.

В обсуждении этой статьи обещал скоро представить развернутые пояснения к их схеме работы с примерами

 

Share this post


Link to post
Share on other sites

Спрошу тут.

Практически допилил интеграцию с онлайн-кассой, используется протокол АТОЛ Онлайн.

Не все понятно с формированием чека. В документации АТОЛ есть куча примеров вплоть до подарочных карт и бонусов, но нет такой банальной операции, как пополнение лицевого счета.

У нас предоплатная система расчетов, абоненты вносят средства на лицевой счет, с который списывается абонплата и предоставляются услуги. Задолженность невозможна, если средств недостаточно, то и услуга оказываться не будет.

Формирую следующий чек:

{
  "receipt": {
    "client": {"email": "user@mail.ru"},
    "company": {
      "inn": "1234567890",
      "email": "provider@mail.ru",
      "payment_address": "Провайдер"
    },
    "items": [
      {
        "name": "Пополнение л/с",
        "price": 123,
        "quantity": 1,
        "sum": 123,
        "payment_method": "advance",
        "payment_object": "payment",
        "vat": {"type": "none"}
      }
    ],
    "payments": [{"type": 1, "sum": 123}],
    "total": 123
  }
}

Тип оплаты 1 (электронно), без НДС.

 

Собственно вопрос — все ли правильно?

Share this post


Link to post
Share on other sites
3 minutes ago, alibek said:

Спрошу тут.

Практически допилил интеграцию с онлайн-кассой, используется протокол АТОЛ Онлайн.

Не все понятно с формированием чека. В документации АТОЛ есть куча примеров вплоть до подарочных карт и бонусов, но нет такой банальной операции, как пополнение лицевого счета.

У нас предоплатная система расчетов, абоненты вносят средства на лицевой счет, с который списывается абонплата и предоставляются услуги. Задолженность невозможна, если средств недостаточно, то и услуга оказываться не будет.

Формирую следующий чек:


{
  "receipt": {
    "client": {"email": "user@mail.ru"},
    "company": {
      "inn": "1234567890",
      "email": "provider@mail.ru",
      "payment_address": "Провайдер"
    },
    "items": [
      {
        "name": "Пополнение л/с",
        "price": 123,
        "quantity": 1,
        "sum": 123,
        "payment_method": "advance",
        "payment_object": "payment",
        "vat": {"type": "none"}
      }
    ],
    "payments": [{"type": 1, "sum": 123}],
    "total": 123
  }
}

Тип оплаты 1 (электронно), без НДС.

 

Это у вас запрос JSON такой улетает к ним?

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

Часть JSON.

да, это конечно же намного проще чем напрямую с драйвером.

Там ведь ( о ужас  ) надо смену открыть и команду обрезки чека подать.  Чистый ассемблер.

 

Share this post


Link to post
Share on other sites
5 minutes ago, alibek said:

 

Не все понятно с формированием чека. В документации АТОЛ есть куча примеров вплоть до подарочных карт и бонусов, но нет такой банальной операции, как пополнение лицевого счета.

 

 

В идеале предмет расчета - услуга, наименование - пополнение л/сч №{из базы сюда}, признак способа расчета - аванс. Т.к. услуга точно не определена и может тратиться и на тв и на инет и на доп. услуи.. Вопрос в момент списания надо ли делать чек на отгрузку этой услуги(и с какими признаком и суммой?)?

Share this post


Link to post
Share on other sites
3 минуты назад, pandatelecom сказал:

В идеале предмет расчета - услуга

Как я понимаю, услуга — это если она оказана или вносимые деньги вносятся именно за услугу.

То есть для постоплатной схемы расчетов.

При предоплатной схеме это просто деньги, которые лежат на счету, пока не потребуется.

 

4 минуты назад, pandatelecom сказал:

Вопрос в момент списания надо ли делать чек на отгрузку этой услуги(и с какими признаком и суммой?)?

Теоретически — должна. Я бухгалтера озадачил этим вопросом, он будет думать.

Но как я понимаю, ближайшие три месяца об этом можно не думать.

 

9 минут назад, LostSoul сказал:

да, это конечно же намного проще чем напрямую с драйвером.

Лучше было бы прочитать название протокола полностью.

Это протокол АТОЛ Онлайн, то есть это онлайн-сервис.

Он намного проще, чем работать с ККТ напрямую.

Share this post


Link to post
Share on other sites
4 минуты назад, alibek сказал:

Лучше было бы прочитать название протокола полностью.

Это протокол АТОЛ Онлайн, то есть это онлайн-сервис.

Он намного проще, чем работать с ККТ напрямую.

Я умею читать, спасибо.  И как выглядят оба протокола примерно представляю, поправлял уже в нескольких проектах код под работу и с тем и с другим вариантом.

 

Смешно мне от того  , что вы считаете будто протокол атол онлайн проще, чем напрямую с драйвером.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now