[alibek]

Спрошу еще.

У нашего сервиса E-COM протокол совпадает с протоколом АТОЛ Онлайн; то ли они его реализуют один-в-один, то ли вообще проксируют.

У нас используется самописный платежный шлюз, он интегрирован с несколькими платежными системами. Правда за исключением Яндекса, у остальных протокол сильно смахивает на ОСМП, ну да не суть.

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

Я бы хотел в чеке (в онлайн-чеке) печатать название платежной системы и идентификатор транзакции. Это возможно?

Правда в схеме пакета 7.2 в чеке я подобных атрибутов не вижу, но мало ли; в схеме у объекта client есть только email и phone, однако мне попадались чеки, в которых указывались имена покупателей.

[deleted]

6 hours ago, alibek said:

Спрошу еще.

У нашего сервиса E-COM протокол совпадает с протоколом АТОЛ Онлайн; то ли они его реализуют один-в-один, то ли вообще проксируют.

У нас используется самописный платежный шлюз, он интегрирован с несколькими платежными системами. Правда за исключением Яндекса, у остальных протокол сильно смахивает на ОСМП, ну да не суть.

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

Я бы хотел в чеке (в онлайн-чеке) печатать название платежной системы и идентификатор транзакции. Это возможно?

Правда в схеме пакета 7.2 в чеке я подобных атрибутов не вижу, но мало ли; в схеме у объекта client есть только email и phone, однако мне попадались чеки, в которых указывались имена покупателей.

Можно к позициям конкатенировать. Она все равно будет одна для аванса..

[LostSoul]

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

Можно к позициям конкатенировать. Она все равно будет одна для аванса..

а для позицией разве еще свобода?

их не нужно выбирать из классификатора, залитого в кассу?

 

( хотя в схеме вероятно будут поля для серийного номера и.т.п. )

 

( собирались, вроде )

 

 

[alibek]

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

их не нужно выбирать из классификатора, залитого в кассу?

Каким образом это будет выглядеть?

Если у меня 50к абонентов, мне нужно загружать в кассу 50к позиций вида "Пополнение л/с #xxx"?

[deleted]

27 minutes ago, LostSoul said:

а для позицией разве еще свобода?

их не нужно выбирать из классификатора, залитого в кассу?

 

( хотя в схеме вероятно будут поля для серийного номера и.т.п. )

 

( собирались, вроде )

 

 

Это только планируется. Пока свобода, пока неполная. Главное чтоб отличить одну от другой. Этот вопрос для уточнения у меня на повестке.

[LostSoul]

29 минут назад, alibek сказал:

Каким образом это будет выглядеть?

Если у меня 50к абонентов, мне нужно загружать в кассу 50к позиций вида "Пополнение л/с #xxx"?

нам еще предстоит это узнать ближе к Июлю.

( это вроде бы уже реализовано для товаров, но еще не придумали как реализовать для услуг )

видимо в схеме будет вариант такой текстовая константа , + поле под номер лс

 

[deleted]

1 minute ago, LostSoul said:

нам еще предстоит это узнать ближе к Июлю.

( это вроде бы уже реализовано для товаров, но еще не придумали как реализовать для услуг )

видимо в схеме будет вариант такой текстовая константа , + поле под номер лс

 

Прослеживается тенденция - запрета указания позиций обобщенно. Хотят максимально точно.

[alibek]

Только что, LostSoul сказал:

видимо в схеме будет вариант такой текстовая константа , + поле под номер лс

Он не решает вопрос.

Например может быть позиция "Пополнение л/с #123 (Яндекс.Деньги)".

Кроме того, есть магазины с миллионами позиций.

Они в кассу просто не влезут.

[LostSoul]

29 минут назад, alibek сказал:

Например может быть позиция "Пополнение л/с #123 (Яндекс.Деньги)".

 

у магазинов с "миллионом позиций" они все уже в кассу влезли, закон обязывает.

ставите тысячу кассу и бьете каждый "отдел" через свою кассу.

 

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

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

 

причем в одном чеке может быть и несколько методов платежа.

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

 

Я так бывает под конец месяца в гипермаркетах плачу -- 10000р с этой карты, 10000р с этой карты и еще 7500 наличными :-)

Все в один чек разом.

 

 

 

[ixi]

В 02.03.2019 в 14:54, alibek сказал:

Например у нас есть тарифы с посуточной абонплатой. Каждый день пробивать чек на 20 рублей за полную отгрузку услуги? 

Было ж вроде, не позднее следующего дня после закрытия расчётного периода.

[alibek]

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

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

По какому именно?

У всех только два способа — наличными и электронно. У некоторых еще отдельно выделяются карточки.

 

29 минут назад, ixi сказал:

Было ж вроде, не позднее следующего дня после закрытия расчётного периода.

Так расчетный период — сутки.

Или я могу сам решить, что будет расчетным периодом?

[deleted]

2 minutes ago, alibek said:

По какому именно?

У всех только два способа — наличными и электронно. У некоторых еще отдельно выделяются карточки.

Карточки - это электронно (безнал). У некоторых просто в API есть что то типа Payment::TypeCARD, что подразумевает передачу способа(типа) оплаты безналичными.

 

2 minutes ago, alibek said:

Так расчетный период — сутки.

Или я могу сам решить, что будет расчетным периодом?

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

[LostSoul]

1 час назад, alibek сказал:

У всех только два способа — наличными и электронно. У некоторых еще отдельно выделяются карточки.

 

у вас указанный классификатор заполнен по умолчанию.

заходите и добавляете туда ещё вариантов, по вкусу.

 

 

1 час назад, alibek сказал:

По какому именно?

У всех только два способа — наличными и электронно. У некоторых еще отдельно выделяются карточки.

  

Так расчетный период — сутки.

Или я могу сам решить, что будет расчетным периодом?

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

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

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

Если вы в договоре/прайсе указали что расчетный период 1 день, то фискализировать наверное каждый день придется :-)

 

[ixi]

1 час назад, alibek сказал:

Так расчетный период — сутки.

Или я могу сам решить, что будет расчетным периодом?

Определения нет, только одно требование -- не больше месяца. Может ли от отличаться, если в договоре у вас прописан день -- тот ещё вопрос.

[Kajamy]

8 часов назад, alibek сказал:

Так расчетный период — сутки.

Или я могу сам решить, что будет расчетным периодом?

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

 

Изменено 4 марта, 2019 пользователем Kajamy

[alibek]

Пошли третьи сутки, пока все нормально.

В ФН память (по паспорту) на 250 тысяч документов, если не злоупотреблять сменами и отчетами, должно получиться тысяч 230-240 чеков.

Если пробивать платежи, должно хватить на 3 года.

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

[deleted]

5 minutes ago, alibek said:

Пошли третьи сутки, пока все нормально.

В ФН память (по паспорту) на 250 тысяч документов, если не злоупотреблять сменами и отчетами, должно получиться тысяч 230-240 чеков.

Если пробивать платежи, должно хватить на 3 года.

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

на отгрузку услуги делаете чек? и какой?

[alibek]

Пока не делаю, время еще есть.

Озадачил бухгалтера, тот пока ответ не дал, думает.

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

Даже с одним чеком в месяц расход памяти ФН удвоится — большинство абонентов платит раз в месяц, плюс еще один чек на реализацию.

[Fint]

Господа. Подскажите есть ряд касс с веб сервером(где это явно написано в описании), для работы с биллингом по эзернету (нет возможности держать кассу в том же месте где сервер) это обязательно? Или можно брать любую с эзернетом, лишь бы была в реестре налоговой? 

[Andrei]

1 час назад, Fint сказал:

для работы с биллингом по эзернету

Т.е. касса сама в биллинг платежи закидывает? Атоллы так умеют?

[Fint]

20 часов назад, Andrei сказал:

Т.е. касса сама в биллинг платежи закидывает? Атоллы так умеют?

Я такого не писал. В моей схеме платеж падает в билилнг, любым способом, биллинг стучит кассе, касса фискалит. Собственно ничего нового, только биллинг и касса физически не в одной стойке, поэтому соединение только эзернет.

[jffulcrum]

@Fint Веб-сервер нужен для многопользовательского режима (работа с кассой в несколько сессий, веб-сервер организует очередь). Без веб-сервера у кассы только один клиент возможен - кто первый встал, того и тапки, и нет никакой очереди - жди конца предыдущей операции перед отправкой следующей. Если клиент - только сервер биллинга, и однопоточная работа, можно брать кассу без веб-сервера. 

 

Касательно работы через Ethernet - порой народ сталкивался с ужасно медленной пробивкой чека, особенно видно при печати. Причина, по словам АТОЛ - алгоритм Nagle, замедляющий отправку мелких пакетов (так как протокол STX имеет размер кадра не более 64 байт). В Linux можно TCP_NODELAY забабахать (или даже low-latency стек TCP какой-нибудь притащить), в Windows тюнится через реестр  TCPNoDelay и TCPAckFrequency.

[Fint]

18 минут назад, jffulcrum сказал:

@Fint Веб-сервер нужен для многопользовательского режима (работа с кассой в несколько сессий, веб-сервер организует очередь). Без веб-сервера у кассы только один клиент возможен - кто первый встал, того и тапки, и нет никакой очереди - жди конца предыдущей операции перед отправкой следующей. Если клиент - только сервер биллинга, и однопоточная работа, можно брать кассу без веб-сервера. 

 

Касательно работы через Ethernet - порой народ сталкивался с ужасно медленной пробивкой чека, особенно видно при печати. Причина, по словам АТОЛ - алгоритм Nagle, замедляющий отправку мелких пакетов (так как протокол STX имеет размер кадра не более 64 байт). В Linux можно TCP_NODELAY забабахать (или даже low-latency стек TCP какой-нибудь притащить), в Windows тюнится через реестр  TCPNoDelay и TCPAckFrequency.

Спасибо за ответ. 

Почему я спросил о необходимости веб сервера, цитата с тематического форума:

 

 "У них сервис облачных касс и там именно они и используют эти кассы, та что в сервисе чек онлайн , да это полноценная касса 1ФА/1ФС но порты все закрыты и подцепить ккмсервер не выйдет, да и собственно надобность в этом отпадает так как там есть api для работы с кассами и изначально на этих кассах уже есть ВСТРОЕННЫЙ http(s) сервер который может принимать запросы по протоколу http(s)
Т.е работа с кассой идет через запросы по http НАПРЯМУЮ"

 

И поэтому решил что JSON-задания лучше отправлять по http. (кассы на подобие Система 1ФА/1ФС, без чекового принтера). И тогда работа по допиливанию биллинга будет проще и дешевле выйдет интеграция.

 

Собственно если не обязателен веб сервер на кассе, то подойдет ли например АТОЛ 30Ф? (дешевле на 4500-5000 руб)

 

И тогда может вообще взять что то максимально дешевое? например АТОЛ 91Ф

Или АТОЛ 92Ф

В этом случае касса с фн выходит уже ощутимо дешевле на 7500р.

[Andrei]

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

Касательно работы через Ethernet - порой народ сталкивался с ужасно медленной пробивкой чека, особенно видно при печати. Причина, по словам АТОЛ - алгоритм Nagle, замедляющий отправку мелких пакетов (так как протокол STX имеет размер кадра не более 64 байт). В Linux можно TCP_NODELAY забабахать (или даже low-latency стек TCP какой-нибудь притащить), в Windows тюнится через реестр  TCPNoDelay и TCPAckFrequency.

Сталкивался с таким при организации  приема платежей для местных энергосетей. Касса Атол была подключена к компу в сети центрального офиса (куда ходит народ со счетами и заявлениями) и этот офис подключен к нам. А бухгалтерский комп с 1С и доступом туда по RDP стоял в другом конце города в диспетчерской энергосетей, подключенной к другому оператору. И в этой ситуации печать чека шла с задержкой до 1 минуты! При этом инет в обоих точках - в офисе и диспетчерской - работал отлично, трассировка между ними тоже никаких проблем не показывала. Так и не решили тогда эту проблему. 

В обеих точках винда. Поискал у себя в Win7 в реестре параметр TCPNoDelay - там он встречается много раз.

Совет, данный тут http://forum.atol.ru/lofiversion/index.php?t35586.html не совсем понял. Как тюнить реестр? Тут народ правильно насоветовал: https://forum.infostart.ru/forum28/topic129091/?PAGEN_1=13 ?

[jffulcrum]

@Fint Тут смотрите, что легче освоить вашему интегратору с биллингом: интерфейсы драйвера ATOL или JSON.

 

@Andrei На Infostart правильно в комменте 1570 написано, надо найти конкретный адаптер в реестре и задать для него.