Перейти к содержимому
Калькуляторы

pandatelecom

Пользователи
  • Публикации

    36
  • Зарегистрирован

  • Посещение

Все публикации пользователя pandatelecom


  1. услуга заранее известна без уточнения параметров - это не предоплата. это тоже аванс.
  2. Это право - не указывать, а не обязательство!!!! ПлатформаОФД - аванс и наименование все нормально пропускает.
  3. Я им об этом же сказал.
  4. LostSoul, вы не в курсе про какие-то драйвера платные от АТОЛ? Недавно был случай у знакомого в связке с 1с и кассой атол - напрямую, через драйвер - задержка до 2 минут. В Атоле (офиц. партнер в регионе) сказали покупайте платный драйвер и все ок будет.
  5. Доброго вечера, дорогие пользователи! Кто нибудь знает про существование универсальных направляющих для серверов. Или вариант только использовать обычные, нетелескопические, стандартные? Или полки? Серверы 1U Dell 1950 PowerEdge. Кто как выходит из ситуации с БУ серверами?
  6. на отгрузку услуги делаете чек? и какой?
  7. Карточки - это электронно (безнал). У некоторых просто в API есть что то типа Payment::TypeCARD, что подразумевает передачу способа(типа) оплаты безналичными. Вроде можно якобы разместить оферту где то на сайте или в месте приема платежей и там написать условия что раз месяц чек, а туда уже все позиции за этот срок, но могу ошибаться. Здесь больше на защиту прав потребителей акцент сделан, а не на сбор в бюджет.
  8. Прослеживается тенденция - запрета указания позиций обобщенно. Хотят максимально точно.
  9. Это только планируется. Пока свобода, пока неполная. Главное чтоб отличить одну от другой. Этот вопрос для уточнения у меня на повестке.
  10. Можно к позициям конкатенировать. Она все равно будет одна для аванса..
  11. Неправильно поняли. касса взаимодействует напрямую с биллингом через облако комтет - как мы и говорили. А интернет эквайринг просто позволяет принимать платежи - за комиссию (тут точно бесплатных нет, это не связанно с кассой). Я вам хотел сказать что одна плат. система предлагает еще такие прокладки но через нее, т.е двойная прокладка - но это уже слишком даже для меня)
  12. Ну в смысле какую из коробочных интеграций с биллингом использовать для приема платежей по картам из лк клиентов. А почему нет. любой интернет эквайринг можно засунуть в кабинеты.. Сейчас посмотрел на их сайте онлайн сервисов мало осталось., а кассы еще остались. я сначала и хотел тоже также как вы.. потом оказалось у биллинга есть модуль для комтета и склонился-купил комтет, но использовать коробочное взаимодействие не стал, написал сам гибче.. ну не буду уж прям ссылаться, но там есть встраиваемые дешевые железки...
  13. Кстати облако облаку рознь. Когда стоял выбор какую плат. систему выбрать для кабинета - одна всем известная крупная, имеющая возможность интеграции с почти всеми сервисми типа бизнес ру или атол онлайн - про некоторые говорит лучше не связывайтесь, постоянно что то не работает, скоро планируется убрать их из списка.. там есть варианты со стационарной кассой, без облака, как вы и предлагаете. И про большинство говорит что не рискуйте.. Железно работают атол, штрих дримкас... опять же скорее всего из-за ПО. Там большинство решений проблемные..
  14. Совместимость антенн 2.4 и 5 ГГц

    в пределах конвертации. заявленные характеристики обратно пропорциональны частотному разбегу.
  15. Недавно подключился, должно катить. платежей еще не было - не могу выгнать из банков людей.. интеграция быстрая - у них прям в кабинете все сам тестируешь (вплоть до проверки несуществующих счетов и платежей с одинаковыми id) и говоришь что все ок. Они все видят и запускают в боевом режиме. Все инструктировано - зеленая зона (отключение 3dsecure) и как сделать url для оплаты и все такое.
  16. Кому то удобно ваше решение, а кому то другое. Для меня критерии: 1. Возможность взаимодействия с использованием общепринятых, открытых и понятных протоколов - это web. 2. Расширяемость. 3. Универсальность. 4. Мобильность. 5. Отказоустойчивость и т.д. Но мыслей чтоб подключить на биллинговую машину железку, потом еще и драйвера поставить для нее, потом еще поставить компилятор для языка api или еще какой-то софт - не возникало... если это конечно не яндекс - бар и не амиго браузер. В моем понятии биллинг - это для внешнего мира веб-сервер, а внутри база, радиус и ядро или либо по кластерам.. Ну давайте word поставим еще и 1с - чтоб бухгалтер мог отчеты делать.. еще флешку с эцп воткнем и пробросим ее как то по сети. Напоминает мне все случай с одним совковым банком в моем регионе, они до сих пор печатают на светодиодных принтерах, а на кнопках в клиент-банке изображены - пробка от coca-cola - типа открыть документ, а коричневый косяк от двери - типа выход из программы. Только недавно вышло приложение на телефон и то стороннее и за баснословную сумму в месяц и подключение не стоит того по деньгам (чтоб вы понимали его еще как-то там подключить надо и все это не шаблонно и трудозатратно - как вам такая масштабируемость??).. И вот уже три года они все делают какое то там онлайн взаимодействие для своей платежной системы, так любят ее, говорят мы не по пути сбера и система город нам не нужна, мы свою развиваем(хотя развития нет).. И тут предлагают типа вашего варианта, но для приема платежей, говорят прям ноу-хау... Ставите клиент банк (а он только на windows === запоминаем), он складывает там реестры в виде файлов, вы их открываете и заносите платежи в биллинг. Ну прекрасно же.. скажите.. Спрашиваю и где тут автоматизация и онлайн? Ну типа эти реестры парсите, потом формируете, другой файл, потом его по фтп отправляете на биллинг, так пишите скрипт - и обрабатываете. Ну прекрасно же.. скажите.. Но, говорят это все очень трудно сделать, т.к. это серьезный уровень, и срок выполнения такой задачи 8 месяцев.. Вот это уровень... не правда ли. Да кстати такими же костылями по фтп я должен загружать базу клиентов к ним, чтобы после обеденного перерыва, когда касса в банке открылась, клиент мог просто сказать свой адрес и заплатить. Т.е мне чтоб это реализовать нужно столько костылей использовать, вплоть до того чтоб на bashе парсить файлы и подключаться по фтп, а на биллинге еще ftp-сервер поднять. А, да еще забыл ваше любимое - сделать код обработки ошибок. ВСЕ ВЫШЕСКАЗАННОЕ РЕШАЕТСЯ ДВУМЯ HTTPS запросами (один проверка л-сч, другой на транзакцию) и двумя ответами, например в виде XML - документа (один выведет информацию, другой скажет платеж проведен - вот статус). Никаких КЛИЕНТ БАНКОВ (в вашем случае драйверов). Вот смотрите, не рекламируя не кого, что имеют в моем варианте пользователи касс: всевозможные библиотеки и готовые модули для crm, битриксов, магазинов, уже продуманные и опробованные решения для бизнес - задач. Пользователь думает максимум об API, и то если ему нужно гибкое решение. Даже в моем биллинге из коробки есть решения для фискализации, и в том числе и комтет. но мне же скучно, поэтому я свое написал. Я бы кстати не стал с вами спорить, если бы речь шла об экономии и при этом у меня был продукт от эвотора. Почему, да потому, что здесь реально появляется смысл поэкономить и заморочиться с драйвером, они монетизируют все, все завязано на андройде и приложениях, не хочешь покупать пиши сам - вот апи на java.... Да даже тот же атол онлайн - дороговато и расширяемость дороже..... а так.. есть конторы все за в пределах 1000 руб. все сделают и поддержат, еще рекламу суй бесплатную в чеке, логотипы вставляй - и все приемлемо и доступно. Еще можно позвонить и спросить мнение эксперта про авансы и чеки коррекции, например.. или еще какие - либо нюансы. На дворе 2019 год - и здесь правит WEB. Никаких плюсов и паскаля на фронте. Некоторые конторы используют вашеподобную схему, но они не видят бэкенд и драйвера, они видят службу поддержки атол и платят также. Вся эта тема хочешь не хочешь легла на продавца и с нее никак не выиграть. появились лишние мысли, расходы и т.д.. Вы уж извиняйте, не хотел обидеть вас, проведя параллель между вашим путем и банковским решением, просто напоминает мне об этом. Мне кажется, что наши истории похожи.
  17. Касса стоит у меня, а в случае если у них - 500 руб замена и открытие фиск. признака. - В любом случае это не те суммы на которых поэкономишь. Ничего мониторить не нужно - придет все на почту если что то случится. Тем, что помимо мониторнга ssd дисковь появляется еще одна задача мониторинга ФН. просто потому что она появляется..
  18. Например, я вообще не завожу и не лезу в драйвер, у меня в каждую транзакцию подгружается из базы тот сотрудник в качестве кассира, через аккаунт которого в админке совершается платеж. Вообще ничего не открывается вручную, никаких команд, и в пределах одной смены - разные кассиры могут делать чеки. Никаких команд и процедур обработки ошибок, мне на почту приходит тикет о проблеме с чеками, например когда инет пропадет где касса стоит. В облачном варианте они все делают сами за 480 руб в месяц. Так же как и вы делаете клиентам не бесплатно же. Никаких заббиксов, сценариев и сайтов офд. Весь контроль и аналитика в кабинете. Никаких сценариев на уведомление на замену ОФД, все делает сервис на почту Тут Вы правы, бесспорно. НО - Бизнес должен заниматься бизнесом а не пониманием логики работы, как и сказал Alibek.
  19. Вам никто и не говорил что это ужас. Расширять и поддерживать проще web-взаимодействие. И ваше решение это тоже путь. Да.. кстати, весь ваш "ужас" начнется с переустановки драйвера(в случае с обновлением)... И это не драйвер написанный HP для железки мирового уровня, а этот драйвер написанный российским интегратором для китайской кассы и их микросхем и т.д. Ваш вариант тоже работает, с вами не спорят. Это ладно мы - хоть как-то приближенные к миру ит, а представьте себе кофейня какая нибудь хипстерская... Лично мне, о чем вам Alibek и сказал, нет смысла экономить 480 руб. в месяц и думать о трех командах, заббиксе, еще о чем то. Например, вы захотите(в вашем случае) использовать кассу еще для чеков с инет-магазина или еще как-то. Как??? Будете поднимать веб сервер, интерпретировать команды, писать интерфейс? нет уже спасибо.. я буду думать об услугах, оптимизации и прочем, буду заниматься естественными процессами. Был бы я, например, региональной сетью продуктовой, например, конечно я бы выбрал ваш вариант, и опять же врядли бы обошлось все тремя командами, скорее всего был бы какой-то аутсорс того же АТОЛ.   В этом то и проблема.. Еще некомпетентность должностных лиц.. Они сами ничего не представляют.. Мне вообще говорили - тебе вообще ничего не надо делать... Технически то уже все ясно...
  20. Значит признак способа расчета "аванс". ..... ну насколько я знаю так.
  21. Предоплатная модель расчетов и признак способа расчетов !== одинаковые вещи. Предоплата - это когда вперед за номер в гостинице №120 на срок 3 дня, а аванс - это когда неизвестно за что, то ли на тв, то ли на инет, то ли на подписку какую нибудь. Если у вас счет пополняется абонентом и 100% идет на определенную услугу, то вам еще нужно определить частичная или полная. или если услуга сразу отгружается, тогда ПОЛНЫЙ расчет(когда услуга в момент расчета).. Где то тут что то не ладное, так как я отправляю с FULLPAYMENT И УСЛУГА - у меня ОФД принудительно ставит АВАНС, а когда FULLPAYMENT и ТОВАР - все корректно.
  22. Нет. Подразумевается предоплата - это когда товар конкретно определен, но передается после оплаты(бывает полная и частичная). Аванс - это когда услуга не определена и оплачивается просто как сумма. Именно в этот момент необходимо выдать чек. Alibek, сообщите что бухгалтер скажет...
  23. В идеале предмет расчета - услуга, наименование - пополнение л/сч №{из базы сюда}, признак способа расчета - аванс. Т.к. услуга точно не определена и может тратиться и на тв и на инет и на доп. услуи.. Вопрос в момент списания надо ли делать чек на отгрузку этой услуги(и с какими признаком и суммой?)?
  24. Это у вас запрос JSON такой улетает к ним?
  25. Вы в чем то правы, а в чем то и нет. Речь идет об использовании драйвера АТОЛ напрямую без Kaas. В этом то и суть - в использовании онлайн сервиса - то, что поддержка более легкой будет, максимум добавится что то, или метод запроса изменится например. Но драйвер предполагает полный контроль над ккт. Тут таки как раз и надо и открыть и закрыть смены, учесть нужный период. При использовании его там ничего не закроется.. Это все делает сервис, он работает с учетом актуальных нововведений и требований с этим драйвером, а с другой стороны предполагает упрощенный вариант взаимодействия с пользователем ккт по web (https запросы). По сути библиотеки в конечном итоге и отправляют все на сервер в облаке таким путем, по https. Команды то можно отправить. Речь идет о поддержке, масштабировании и соблюдении законодательства.. Например приведу, в каком случае было бы сделать легче - используя онлайн сервис с его API или напрямую используя драйвер, т.е. без использования сервиса Kaas случай внедрить исполнение новой версии ФФД 1.05?? В первом случае нужно платить за это, а во втором поддерживать самому, что кажется дороже.. Насчет курьеров вроде развозная торговля - но могу ошибаться и там место расчетов может быть даже номер авто указан - этот момент самый раскрытый в сети и там много практических решений и примеров. Опять же без онлайн сервиса не закроется ничего, закроет только прослойка (Kaas) между пользователем и ККМ, использую этот драйвер. Сервисы все насколько я знаю предполагают покупку ФН, так как это требования закона, просто его вставят в свою кассу (причем этот ФН теперь только с этой кассой только будет работать) и разместят у себя, некоторый предлагают купить все и разместить у пользователя. изменятся НПА.... В том то и дело изменится и АПИ, а в случае с драйвером посложнее все будет.. но можно. Ребята, связанные с кодингом поймут. Я сейчас не топлю за покупку этих сервисов, самого бесит эта телега в коробке два зарядника, микрокомпьютер и касса - такой колхоз.. просто самый дешевый вариант таков был на тот момент.