RSS
QR code?
 
Коллеги, подскажите как Вы технически вставляете в квитанцию штрих-код или QR code. На прошлой неделе позвонили из отдела, который начисляет в ГИС ГМП платежи, потом смотрит оплачены ли там же (ну про ГИС ГМП отдельный разговор, на данный момент они могут туда вручную занести начисление и оттуда УИН увидеть, который и требуется в QR внести), сказали что хотят штрих-код вставить в квитанцию.

Что-то я не знаю с чего начать - на текущий момент квитанция у них вроде бы в ворде, просто меняют ФИО и сумму, в 1С не работают. Из ГИС ГМП можно распечатать PDF-квитанцию стандартного образца с заполненными цифрами и ФИО, но без QR кода. Нашел сервисы в интернете, которые формируют по строке картинку QR, нашел как строку с УИН составить, интересует как кто решил автоматизировать вставку картинки - вручную в ворд они такого навставляют, что будет ужас. Навскидку думаю Эксель как-нибудь задействовать (например получить из страницы ГИС ГМП список начислений и УИН, сформировать из них строку, получить картинку, разместить на болванке квитанции), но может быть есть готовые решения?
 
Уже второй год печатаем квитанции из 1С c QR. Формат Сбера. В чем проблема то собственно?
Или нужно именно НЕ в 1С?
 
Цитата
two_oceans пишет:
Навскидку думаю Эксель как-нибудь задействовать

в Экзеле есть пару примеров QR кода но все через Ж.... сделано, я не смог победить (победил линейный штрих). Во вложении, что в интернете нащел.
 
Цитата
Форест пишет:
Или нужно именно НЕ в 1С?
Спасибо за ответ. В общем да, 1С бы все решило (в сферическом вакууме), но есть нюансы.

1) В том подразделении работают не бухгалтеры, их учить на 1С будет несколько проблемно; 2) скорее всего бухгалтерия будет против допуска этих сотрудников к конфигурации БГУ; 3) люди к ним обращаются разово, так что смысла держать базу на всех "клиентов" тоже нет - это база на весь город получится; 4) помимо того, они вообще находятся в отдельном здании и не в нашей ЛВС, так что открытие доступа к 1С прилично снизит безопасность, попытка подключить по гост-шифрованию пока неудачна; 5)в довершение наша 1С пока не связана с ГИС ГМП и острой необходимости ее связывать нет - начисления только у этого подразделения и еще одного (остальные муниципальные услуги без платы).

Итого выбор - покупать для них отдельный сервер и мутить отдельную 1С со связью ГИС ГМП либо решать по-другому. Честно, я больше склоняюсь к своей ИС. Но наверно это идея - посмотреть есть ли у нас QR в 1С и найти какая библиотека за него отвечает - так можно от веб-сервиса избавиться.
Цитата
Форест пишет:
Формат Сбера.
Так, а есть какой-нибудь пример как располагать QR. Кто пишет слева, кто справа, на картинках вообще как только не располагают.
Цитата
в Экзеле есть пару примеров QR кода но все через Ж.... сделано, я не смог победить (победил линейный штрих). Во вложении, что в интернете нащел.
Спасибо, поразбираюсь. Пока нашел [url:w618mwcx]https://infostart.ru/public/604539/[/url:w618mwcx] - предлагают ActiveX компонент, наверно для Экселя подойдет.
 
Если для 1С - самый отличный пример в демо-конфе БСП.
Насчет расположения - я расположил там где мне показалось удобно)
Единственный нюанс - попросили если в платежке 2 кода - не располагать их слишком рядом.
 
Итак, первые результаты - ActiveX конечно замечательный - без проблем ставится на форму в VBA и поддерживает огромную кучу форматов кодов, в том числе и QR. Однако на лист Экселя ставиться наотрез отказывается. Но некий прогресс есть.
Поковырял 1С на предмет кодов - в конфигурации обнаружилась бинарная компонента для QR (для штрих-кодов есть еще одна), сохранил в файл. Файл оказался zip архивом, внутри библиотеки под разную разрядность windows/linux и манифесты (к слову, для xmldsig, xades компоненты тоже нашлись... для IE и FF).

Однако как с библиотекой работать пока не разобрался - в экспорте указаны 3 наименования: GetClassNames, GetClassObject, DestroyObject, судя по описанию это "NativeAPI" внешняя компонента. Нашел пример как написать и работать, так там еще классу передается ссылка на объект платформы 1С и менеджер памяти.
 
Цитата
two_oceans пишет:
Однако на лист Экселя ставиться наотрез отказывается.
Рекомендую попробовать это: [url:12p3el4q]http://delphi32.blogspot.ru/2013/09/quricol-20-qr-code-generator.html[/url:12p3el4q]
 
Цитата
Basil пишет:
Рекомендую попробовать это: http://delphi32.blogspot.ru/2013/09/qur ... rator.html
Спасибо. Насколько вижу это голая библиотека + юниты для Дельфи и .Net. Как вставить картинку на форму Дельфи вижу в примере, а вот как это совместить с Экселем еще надо поломать голову. Конечно на Экселе свет не сошелся, можно в Экселе ввести реквизиты, а в html сформировать квитанцию, так что виден свет в конце тоннеля. Наверно можно еще проще сделать печатную форму через компоненты Дельфи, но у меня только Дельфи-совместимый компилятор Паскаля, с компонентами все сложно.

Навскидку есть простой способ совмещения с Экселем (сформировать программой bmp файл в Паскале, потом в Экселе загрузить его в стандартный элемент управления картинка, который на лист Экселя прекрасно ставится ), но тогда будет бардак с этими файлами из-за синхронизации 2 приложений.

Скорее всего посмотрю в сторону вольной имитации common gateway interface: передать строку реквизитов на поток ввода или как параметр командной строки программы на Паскале, закодировать результат (стрим) в Base64, обернуть каким-нибудь тегом и вывести на поток вывода (либо в html файл, вместе с реквизитами). В принципе все исходники для этого есть - только немного типы стримов подогнать. И для потенциальной ИС подойдет.

Либо поток вывода можно перехватить функциями VB (родительский процесс может получить доступ к дочернему процессу), убрать тег, декодировать (тоже исходники есть) и как-то загрузить в картинку в Экселе (не пробовал в элемент управления картинку из памяти грузить, вроде бы там тоже требуется перевести в IDispPicture, то есть тоже все придет к файлу на диске, что печально).
 
Цитата
two_oceans пишет:
Навскидку есть простой способ совмещения с Экселем (сформировать программой bmp файл в Паскале, потом в Экселе загрузить его в стандартный элемент управления картинка, который на лист Экселя прекрасно ставится ), но тогда будет бардак с этими файлами из-за синхронизации 2 приложений.
Можно вставлять на лист просто как рисунок, после этого сам файл не нужен, его можно удалять.
 
Согласен, если "внедрить" рисунок. Хотя затруднение не столько в количестве - начислений в этом подразделении не так уж и много (несколько десятков в месяц), но они делаются сразу группой за прошедшую пару недель, и есть некоторый шанс, что второпях вставят картинку от другой квитанции, а это плохо. В идеале - вообще бы не хранить картинку отдельно от квитанции, потому сгенерировать html в качестве печатной формы возможно будет беспроблемней.
Хотя в другом подразделении собираются грузить данные сотнями, но там собираются 1С подключить, так что для них мне главное связь наладить, а с квитанциями сами разберутся.
 
Итак, тестовый вариант сделал на основе quricol. Программка считывает текст из текстового файла (в UTF-8), получает PNG в буфере (модуль дельфи с объектом не подошел, потому что компилятор не Дельфи и модуль Graphics не нашелся, а вот модуль описания библиотеки оказался в кассу, но не удалось заставить библиотеку сохранить в файл напрямую, впрочем из буфера прекрасно записывается в файл). Потому я сразу закодировал содержимое буфера в base64 и вывел в виде тега img в html файл. Оттуда скопипастил в html шаблон квитанции с реквизитами, распечатал - выглядит замечательно, но меньше чем образец ПД-4 от Сбербанка.
Затем пошли проблемы - отсканировали через мобильное приложение сбербанка и получили сообщение "поставщик не найден в регионе". dash2 Поэтому вопрос - еще надо как-то регистрироваться у банков или что? Проверил по сервисам расшифровки - вроде бы никаких посторонних символов вроде Byte Order Mark не заметил.
При этом, если в Сбербанк Онлайн выбрать Госпошлины - федеральные сервисы - госуслуги - оплата по УИН и скопировать номер начисления, то Сбербанк подтягивает все реквизиты (в том числе КПП) и сумму правильно. Получатель написан 2 раза вверху Госуслуги, внизу реальная организация. Была шальная мысль назваться госуслугами. :lol:

Кстати - еще вопрос про сумму - указывается в копейках (по стандарту) или в рублях? Для образца расшифровал QR на счете за интернет от Ростелекома, там указано в рублях (лицевой счет замаскировал).[code:2pzdd7au]ST00012|Name=ИРКУТСКИЙ ФИЛИАЛ ПАО "РОСТЕЛЕКОМ"|PersonalAcc=40702810244070103792|BankName=СИБИРСКИЙ БАНК ПАО СБЕРБАНК|BIC=000000000|CorrespAcc=30101810500000000641|PayeeINN=7707049388|Sum=118|PersAcc=XXXXXXXXXXXXXX[/code:2pzdd7au], то есть только заголовок, 5 обязательных реквизитов, инн получателя, сумма и лицевой счет, а у меня побольше данных и сумма в копейках [code:2pzdd7au]ST00012|Name=УФК ПО ИРКУТСКОЙ ОБЛАСТИ (xxx)|PersonalAcc=40101810900000010001|BankName=ОТДЕЛЕНИЕ ИРКУТСК|BIC=042520001|CorrespAcc=0|PayeeINN=38xxxxxxxx|KPP=38xx01001|CBC=xxxxxxx0040040000140|OKTMO=25xxx000|Purpose=xxx|Sum=150000|LastName=xxx|FirstName=xxx|MiddleName=xxx|UIN=0xxxxxxx00010000000005035|TechCode=03|PayerIdType=01|PayerIdNum=xxxxxxxxxx[/code:2pzdd7au]Насчет TechCode (код указыващий, что госуслуги, штрафы, госпошлины) и PayerIdType (тип документа удостоверяющего личность - не нашел таблички что писать для паспорта рф, написал 01) сомневаюсь - может убрать их "для ясности".

Для эксперимента в этом месяце выдали автоматически сформированные квитанции из ГИС ГМП (без QR, но с УИН) - и нам уже принесли копию чека. Вот только там в чеке паспорт 1231231233 ("123" 3 раза и еще "3") и УИН 0. То есть без QR никто даже и не думает вбивать паспорт и УИН в терминале. Начисление автоматом не сквитировалось. :(
 
Цитата
two_oceans пишет:
Кстати - еще вопрос про сумму - указывается в копейках (по стандарту) или в рублях?
В копейках. ГОСТ
 
Да, именно на такой ГОСТ я и ориентировался (только проект без окончательного утвержденного номера). Однако у Ростелекома в счете было 118 рублей 00 копеек и в расшифровке сумма 118, то есть указана в рублях. dash2
Поэтому сомнения остались. ГОСТ на QR вообще практически соблюдается относительно указания суммы в копейках? Или как в ГИС ГМП - написано в документации "сумма в копейках", а на практике указывают в рублях (о чем сформировано техническое задание разработчикам, но его не спешат выполнять: начисление может несколько лет висеть, причем оно подписано ЭП и потому просто так сумму из старых начислений не пересчитать). Я так понимаю без проверки на практике не обойтись?
 
Цитата
two_oceans пишет:
Я так понимаю без проверки на практике не обойтись?
Из опыта работы со Cбером. Мы использовали линейный штрихкод, год назад перешли на QR. Заключили доп.соглашения, в которых в том числе оговаривался состав показателей, передаваемых в QR. И только после того, как они провели у себя какие-то настройки, одномоментно в терминалах перестал распознаваться линейный, и начал - QR. А до этого на QR выдавалось сообщение типа "Поставщик не найден". То есть, у получателя средств должен быть договор с банком на прием с использованием QR.
 
Ясно, спасибо за полезную информацию. В принципе если с одним банком, то наверное можно и сделать доп.соглашение. У нас в городе несколько банков - постоянно отслеживать новые и заключать соглашения еще та головная боль. А если учесть что в перспективе это же также нужно и подразделениям, выделенным в юридические лица, то становится вообще печально.

Все же предполагаю, что для начислений ГИС ГМП в частности, должно быть по другому - пункт про госуслуги и оплату по УИН по любому уже есть в терминале и мобильном приложении Сбербанка, раз есть на Сбербанк онлайн. Вопрос в том, как "назваться" чтобы он автоматически выбрался (ну не будет никто искать в глубине меню пункт и вбивать 25 цифр УИН), а не искал неведомого и ненужного "поставщика в регионе" (УИН единый и Госуслуги доступны для всех регионов). Похоже без письма в банк мы это не узнаем.
 
Цитата
two_oceans пишет:
Насчет TechCode (код указыващий, что госуслуги, штрафы, госпошлины) сомневаюсь - может убрать их "для ясности".

У нас в договоре со Сбером- ТехКод обязательный реквизит. По нему разделены основные квитанции и квитанции на пени. Люди при оплате через СБ Онлайн выбирают соответствующую иконку - Оплата ЖКУ, Оплата Пени.
 
Цитата
Форест пишет:
У нас в договоре со Сбером- ТехКод обязательный реквизит. По нему разделены основные квитанции и квитанции на пени. Люди при оплате через СБ Онлайн выбирают соответствующую иконку - Оплата ЖКУ, Оплата Пени.
Это замечательно, хоть какая-то наводка на выбор в меню терминала. Вот только у меня ноль процентов уверенности, что техкод у Сбербанка совпадает с рекомендуемой таблицей из ГОСТ и нужно указывать именно 03 для госпошлины/штрафа. А если люди что-то другое выберут и приложат QR с TechCode не подходящим к выбранному пункту? не сработает? Так может у меня не сработало из-за неверного техкода? Выходит к ПД надо еще и инструкцию прикладывать - куда тыкать?
Более того, задали вопрос техподдержке ИС через которую выходим в ГИС ГМП, они сообщили что для квитирования нужны только УИН и сумма, потом на наши вопросы видимо тоже загуглили и прислали ссылку на статью, в которой преимущественно пересказан ГОСТ, но кроме того выдержка на какой-то документ по API для штрихкода, там BANK_NAME вместо BankName. Хотя может быть это только при обращении к API так поля названы, а выходит нормально.
 
Не знаю как в других регионах, у нас я так понимаю эти техкоды прописываются в договоре и там описано что есть каждый код.
Соответственно у меня код 2 это пени, а у кого то код 2 это - слив стояков (реально такое есть)).
 
Цитата
Форест пишет:
Соответственно у меня код 2 это пени, а у кого то код 2 это - слив стояков (реально такое есть)).
Жесть. Вспомнилось "Этот демон еще и динамический!"
 
Господа, подскажите, пожалуйста, в каком документе описан состав полей QR-кода применительно именно к ПД ГИС ЖКХ. Чё-то, никак найти не могу нигде. Помню, что UIN=Ид.ПД, а вот в каком теге ЕЛС указывается - забыл напрочь.
 
Цитата
AlcorVol пишет:
Господа, подскажите, пожалуйста, в каком документе описан состав полей QR-кода применительно именно к ПД ГИС ЖКХ. Чё-то, никак найти не могу нигде.
Выложен в "Регламентах и инструкциях" в открытой части ГИС
 
Цитата
Andrey_S пишет:
Выложен в "Регламентах и инструкциях" в открытой части ГИС
Спасибо, Андрей! ЕЛС'а отдельно, получается, всё-таки нет? Только в составе uin?.. Это мне не очень подходит. Причём, сразу по двум причинам. Во-первых, все мои УК и ТСЖ печатают квитки до загрузки их в ГИС. ЕЛС известен, но Ид.ПД - не вполне пока понятен (последний знак). И самое главное, все мои УО погашают оплатой самую старую задолженность. Поэтому я никогда не указываю тег paymPeriod и не хотел бы указывать и uin. (Это к вопросу о пресловутом квитировании).
 
Цитата
AlcorVol пишет:
Во-первых, все мои УК и ТСЖ печатают квитки до загрузки их в ГИС. ЕЛС известен, но Ид.ПД - не вполне пока понятен (последний знак).
Нужно менять свои бизнес-процессы, несколько раз писал об этом.
Цитата
AlcorVol пишет:
И самое главное, все мои клиенты погашают оплатой самую старую задолженность. Поэтому я никогда не указываю тег paymPeriod и не хотел бы указывать и uin. (Это к вопросу о пресловутом квитировании).
При регулярной своевременной оплате "Сумма документа с учетом задолженности/переплаты" совпадает с "Суммой документа". В наших местах (думаю, и везде) большинство потребителей-физлиц выполняют оплаты регулярно и своевременно. Без указания периода или ИПД автоквитирования не будет заведомо.

Технически же в реквизит uin можно писать и ИПД, и ИЖКУ, и ЕЛС - по нашей практике никто в этом отношении палок в колеса не ставит - содержимое этого реквизита не контролируют, просто при размещении факта оплаты в ГИС кладут его в поле ИПД.
 
Цитата
Andrey_S пишет:
Нужно менять свои бизнес-процессы, несколько раз писал об этом.
Спасибо, читал. Но всё зависит не только от меня, но в первую очередь - от клиентов-УО.
Цитата
Andrey_S пишет:
При регулярной своевременной оплате "Сумма документа с учетом задолженности/переплаты" совпадает с "Суммой документа".
С этим никто не спорит. Но алгоритмы должны учитывать не только эти случаи, но и нестандартные. Когда плательщик - должник. И когда человек платит авансом. Я бы даже сказал, что учёт нерегулярных случаев - это основной объём кода программы.
Цитата
Andrey_S пишет:
Технически же в реквизит uin можно писать и ИПД, и ИЖКУ, и ЕЛС - по нашей практике никто в этом отношении палок в колеса не ставит
А вот за эту инфо - спасибо!

В любом случае, механизм "квитирования" меня (и моих клиентов) не устраивает совершенно. Входящее сальдо, оплату за месяц и сумму к оплате УО способна вычислить самостоятельно. И в ПД есть соответствующие поля. Квитирование - вообще лишняя вещь.
 
Цитата
AlcorVol пишет:
В любом случае, механизм "квитирования" меня (и моих клиентов) не устраивает совершенно. Входящее сальдо, оплату за месяц и сумму к оплате УО способна вычислить самостоятельно. И в ПД есть соответствующие поля. Квитирование - вообще лишняя вещь.
Она не лишняя, сложность объективна и вызвана переходом к другому уровню учета.
Поставщики ЖКУ привыкли вести учет "сальдо взаиморасчетов в целом по лицевому счету". При том, что в нормативке (еще "догисовской") указано, что плательщик при совершении платежа вправе указать, за какой период погашается задолженность. Кроме того, от задержки погашения задолженности зависит размер пени.
Из этого следует необходимость учета взаиморасчетов по периодам, т.е. по выставляемым платежным документам. Она и реализована в ГИС ЖКХ - в других учетных системах (например, "управление торговлей" от 1С) подобное тоже бывает, называется "учетом взаиморасчетов по документам расчетов с контрагентами".

По поводу часто встречаемого тезиса "мы же и так указываем задолженность при размещении платежных документов":
В ГИС ЖКХ изначально заложен принцип учета на основании ПЕРВИЧНЫХ документов (в том числе и при учете оплат). Первичным документом о совершении оплаты является документ, фиксирующий операцию приема денежных средств от плательщика, а не сводная информация об оплатах, получаемая от поставщика ЖКУ (т.е. потенциально искаженная им - кстати, рекомендую всем просто проверить, всегда ли корректно у вас самих размещается в ГИС ЖКХ "Сумма документа с учетом задолженности/переплаты"? - мы в ходе работ по направлению квитирования отловили и устранили несколько систематических ошибок). Кроме того, в биллинге поставщиков ЖКУ нередки прецеденты "невыясненных платежей" - заложенный в ГИС ЖКХ принцип создает предпосылки к устранению этого явления.
 
Схема изначально некорректна (в общем случае).
См. здесь:
viewtopic.php?p=181995#p181995
 
Сводный справочный файл по общефедеральным шаблонам договоров Сбербанка (сбор платежей от физлиц)

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!