new_year

Форум

Главнаяtwo_oceans

two_oceans

Форум

Дата создания

Выбрать дату в календареВыбрать дату в календаре

Тема

Сообщение

Упорядочить

Выбрать дату в календареВыбрать дату в календаре

Ошибки в ГИС (эмоции пост)
 
[QUOTE]Анимаиса пишет:
Сегодня пыталась поработать с ГИС.[/QUOTE]Первый скриншот это ГИС ЖКХ, второй ЕСИА. Не надо к ГИС еще и ошибки ЕСИА списывать, у ГИС и так хватает. :lol:
Хотя конечно мне тоже не особо нравится как реализована ЕСИА - ни назад не тыкнуть, ни на исходную страницу откуда на ЕСИА перекинуло не перейти, приходится или править вручную в строке адреса или из закладок открывать.
Платежные реквизиты
 
[quote:2qigls66]Каждая сторона грузит только свои услуги своим ПД со своими реквизитами[/quote:2qigls66]Примечание. Конечно, теоретически, одна организация может добавить реквизиты другой и включить услуги другой организации в ПД, однако там есть заморочки как с реквизитами, так и со связанными данными, например, показаниями ПУ, которые потянут ДРСО и т.д.
Платежные реквизиты
 
[QUOTE]andreas_2017 пишет:
Подобная же ситуация. Есть платежный агент, через которого производятся платежи жильцов. При импорте платежных документов из бухгалтерской программы выходит ошибка - несоответствие реквизитов (в ГИС'е у платежного агента указаны реквизиты его, у УО - её реквизиты и указан платёжный агент с реквизитами, размещён договор с платёжным агентом; в импортируемых платежных документах указаны реквизиты платежного агента для проведения платежей). Писал в техподдержку - посоветовали добавить реквизиты платежного агента к своим. Но ведь это по сути не правильно ?[/QUOTE]Да, очень похожая ситуация (за исключением того, что у расчетного центра в ГИС вообще не предполагается прием на свой счет, а у платежного агента допускается, если он сам предоставляет услуги). Как я понял из сообщения, УО пытается импортировать платежные документы в которых реквизиты платежного агента? Это неправильно, укажите в платежных документах реквизиты УО. Добавление реквизитов предназначено для случая, когда в ПД включаются услуги, которые предоставляет другая организация. Если сделать по совету техподдержки, то выйдет, что услуги предоставляет платежный агент, а УО вообще не причем.

Поясню, как я все это понимаю. "у УО ... указан платёжный агент с реквизитами, размещён договор с платёжным агентом": указание платежного агента делается для того чтобы платежный агент смог разместить [B][U]платежи[/U][/B] с указанием реквизитов УО (без этого агент сможет принимать платежи только на свои реквизиты), а не для того чтобы УО могла разместить ПД с реквизитами агента. Другими словами, реквизиты указываются для размещения ПД (например, одна организация размещает услуги в одном ПД за несколько организаций), а платежные агенты и договора указываются для размещения платежей.
Делаем вывод: если в платежах от платежного агента будут указаны конечные реквизиты УО (а именно это подразумевается при указании платежного агента и договора), то в платежных документах, чтобы они сквитировались с такими платежами, также должны быть указаны реквизиты УО.

Если и в ПД и в платежах указаны реквизиты УО, то УО сможет их квитировать как автоматическом, так и в ручном режиме. Разные реквизиты приведут к невозможности квитирования. Если же и в платежных документах и в платежах указаны реквизиты платежного агента и агент не УО/РСО, то ручное квитирование будет невозможно, про автоматическое не могу с уверенностью сказать.

Допустим, платежный агент принимает платежи в кассу, потом сдает на свой счет (но эти операции не отражаются в ГИС), потом переводит на счет УО (это отражается в ГИС, указываются реквизиты конечного получателя - УО). С отражением могут быть проблемы, если платежный агент перечисляет всю сумму за день одним платежем, ведь в ГИС как минимум на каждый ЛС, а лучше на каждый ПД (а ПД может быть на каждую услугу и месяц по одному ЛС) должен быть отдельный платеж на счет УО. Это значит либо переводить кучу мелких платежей и указывать их реальные платежные идентификаторы в ГИС, либо послать одной суммой, но выдумать кучу "виртуальных" идентификаторов платежа при размещении в ГИС.

Немного сложнее случай когда, например, одна организация УО + платежный агент для РСО, вторая организация - РСО + платежный агент для УО. В таком случае, договоры с другой организацией как с платежным агентом предполагаются у обеих сторон. Каждая сторона грузит только свои услуги своим ПД со своими реквизитами, и соответственно размещает платежи за свои услуги на свои реквизиты, платежи за услуги другой организации на реквизиты другой организации.
Платежные реквизиты
 
Не понятно при чем здесь расчетный центр и его реквизиты - ведь расчетный центр не предоставляет услуги и ресурсы. В платежке они должны заполнить реквизиты конечного получателя (УО или РСО, например), который предоставляет услуги и ресурсы. Точную ссылку на нормативку не вспомню, но предполагалось, что расчетный центр не должен крутить деньги на своих счетах, а в течение суток перечислять на счет конечного получателя, то есть для ГИС в плане платежей он как бы не существует.

Если заполнить в платежке реквизиты расчетного центра и если расчетный центр сам не УО/РСО до кучи, то сквитировать платежи никто не сможет: у функции расчетного центра нет такого интерфейса, интерфейс есть у конечной организации, но конечная организация не увидит в нем платежи по платежкам с реквизитами расчетного центра. В случае, если конечная организация делегирует полномочия расчетному центру как оператору ИС, то расчетный центр сможет увидеть и сквитировать только те платежки, в которых указаны реквизиты конечной организации, делегировавшей полномочия, но все равно не увидит в ГИС платежи, в которых реквизиты самого расчетного центра (хотя и увидит их на своем счете). Получается, сейчас грузите платежки ради того чтобы грузить, но они всегда будут не квитированы в личном кабинете гражданина.

Если Вы предоставляете услугу и деньги в конечном счете приходят Вам, то Вам нужно делегировать расчетному центру полномочия по выгрузке платежек, а расчетному отправлять платежки от Вашего имени (с Вашими реквизитами), а не от имени расчетного центра. В этом случае, они не увидят деньги на своем счете, но увидят по делегированным полномочиям платежи в ГИС. Короче, они затупили, пытаясь отправить платежки с их реквизитами, еще и Вас в заблуждение ввели. Либо просто хотят крутить деньги на своем счете.
Ошибки в ГИС (эмоции пост)
 
Ну а что... добавили поле, закрыли заявку в жире, потом убрали поле и все шито-крыто - заявка то закрыта уже.
Лицевые счета. Загрузка в систему.
 
[QUOTE]Sergey_P пишет:
отчество не является обязательным полем[/QUOTE]Отчество естественно не обязательное, но в файле фамилия 1, имя пусто, отчество 1. Имя все же обязательное поле.
Ошибки в ГИС (эмоции пост)
 
исправляют ошибки после исправления ошибок - наверно по большей части откатывают исправления)))
Лицевые счета. Загрузка в систему.
 
1) "счета разделены" = "Да" должно быть только в тех строках где указан номер комнаты (у Вас только пять таких строк). Для таких вроде бы нужно указать снилс или паспортные данные, то есть указывая  "счета разделены" = "Да" и не указывая снилс или паспортные данные вы уже сразу выкидываете все строки в ошибки.
2) ФИО 1 1 1 также весьма интересно, пустое поле имени при заполненном отчестве тоже не очень хорошо. Не уверен, как ГИС на это среагирует, но я бы на месте ГИС на них ругнулся. А как это сработает с признаком разделения - вообще сложно предугадать. Вдруг их потом сведет в одну платежку?
3) почему тип счета "ЛС УО", когда основание "Договор ресурсоснабжения (ЛС РСО или ЛС РЦ)" - что-то тут не так. Этим также выкидываете все строки в ошибки. Если Вы РСО (в том числе, если одновременно и УО и РСО - тогда Вы не можете заключить договор сами с собой и не сможете выстроить цепочку ресурсоснабжения как УО, но сможете трактовать все договора как прямые с РСО) - ставьте ЛС РСО; если Вы РКЦ и хотите выставить единую платежку - ставьте ЛС РЦ; если РКЦ без единой платежки - ждете пока ЛС загрузят УО/РСО и получаете к ним доступ; если Вы УО, но не РСО, то ставьте другое основание. Хотя в случае УО вполне возможно, что счета должны загрузить РСО или РКЦ, а Вам вообще не нужно парится с ЛС. Чтобы сказать точнее нужно больше информации - кто исполнитель, договора какие заключены, в чьей собственности оборудование и т.д.
Опрос по модулю "Квартплата" в СРМ системе
 
Молодцы, так постепенно и Бурмистр и напишет свою ГИС. qws Классная идея с единой экосистемой, но будет ли востребовано именно начисление неизвестно. Основное сомнение - по поводу интеграции с другими системами. Как минимум потребуется интегрироваться с 1С из-за платежей идущих мимо ГИС и налоговой отчетности. Выше уже сказали про эквайринг, начальную массовую загрузку (ну правда, много ли найдется программистов запилящих выгрузку всех данных из их системы, чтобы от их системы отказались - значит Вам придется эти данные как-то выколупывать из других систем), наверняка еще много чего потребуется чтобы всех удовлетворить.
Второе - сейчас каждая УО и РСО считает по-своему, по форуму это отчетливо видно. Если делать вариант под каждого - получится махина не меньше ГИС, но и подвести всех под один знаменатель тоже непростая задача (некоторые бухгалтеры ну очень уперты и будут считать как привыкли даже если это уже ни с каким законом не совпадает). В этом смысле можно пожелать какой нибудь мастер настроек по вопросам (вроде таких: Вы предоставляете услугу? В чьей собственности бойлеры? Используются прямые договора?) предлагающий варианты расчета.
Третье - "тыдыщ и все сделаем" замечательно, но чем больше функций в системе, тем меньше будет времени у программистов на каждую функцию. С выгрузкой в ГИС тоже как-то легко написали, как будто ГИС завтра начнет работать как положено.
Четвертое - браузер это замечательно, но при расчете будет много персональных данных, так что планируется ли настраивать криптотоннель по ГОСТу для работы? Если да, то будет ли собственный внутренний УЦ или будут использоваться сертификаты аккредитованных УЦ.
Пятое - минус всех "облачных" систем - интернет отрубили и все, приехали.
Итого: наверное нужно реализовать наиболее популярные варианты в полной мере и посмотреть что выйдет.
Внесение информации председателем МКД
 
Ради интереса посмотрел у ОМСУ и тоже что-то не вижу функционала.
Предоставление информации о ПУ
 
[QUOTE]Шла_мимо пишет:
Программно-то как удалить???? Куда обратиться или на какую кнопку тыкнуть?[/QUOTE]Кнопочку? Мечтать не вредно)))
Во-первых, нужна информационная система. Можно использовать 1С как информационную систему. Обратиться к разработчикам 1С по поводу интеграции с ГИС Вы конечно можете, допустим даже Вам сделают, но скорее всего это будет за отдельные деньги.

Цитирую из чата разработчиков интеграции: "в 1С мертворожденные функции подписания", написавший это делает xml в 1с потом подписывает/отправляет через другую программу, обещал как более-менее отладит взаимодействие взяться за подписание в 1С и поделиться результатом. С учетом что все время что-то меняется, отладит еще не скоро.

Во-вторых, информационную систему нужно зарегистрировать в ГИС и наладить соединение. Сначала надо настроить криптотуннель к серверам ГИС и пройти тестирование, для криптотоннеля и подписания требуется КСКП (сертификат электронной подписи) с указанным классом защиты КС2 (то есть вероятно придется получать новый, если у Вас только КС1). Используете ли реально требования класса защиты КС2 им до лампочки, но в сертификате смотрят. С 1 февраля 2018 года еще нужно отправлять айпи-адреса с которых будете обращаться к ГИС, тестовые сервера теперь не отвечают на запросы пришедшие с "левых" адресов. То есть если у Вас динамический айпи (адрес меняется каждый раз при подключении), то надо будет докупить статический у своего провайдера. Потом добавить своей организации полномочия оператора ИС, подождать пока утвердят. Дать разрешение информационной системе на доступ к данным организации. Тогда может быть что-то сможете делать интеграцией, но не сможете править через личный кабинет.
Если краткое описание не напугало и нужны подробности, спрашивайте в [URL=http://forum.burmistr.ru/viewforum.php?f=147]ветке программистов[/URL].

В-третьих, после всего этого геморроя - оно еще и не работает! Разработчики интеграции жалуются и на отсутствие соединения с серверами ГИС и на долгое нахождение запроса в статусе 1 (принят, но не обработан). Техподдержка рекомендует если запрос висит неделю в статусе 1, забывать про него и отправлять снова.Короче, говорят, проще нанять китайских детей для занесения/архивирования чем пилить интеграцию.
Ну, что проявим фантазию? Или когда менять «стандартное» название УК на уникальное.
 
[QUOTE]Joli пишет:
управляющая в принципе не сможет работать и обслуживать дома в другом регионе, поэтому вполне допускаю что в субъектах могут существовать уо с одинаковыми названиями[/QUOTE]Допустим, по той же лицензии в другом регионе не сможет, но теоретически получить еще одну лицензию в еще одном регионе что-то помещает? Хорошо, пусть не получит вторую лицензию и не обслуживает в другом регионе, но смешивать то предположительно будет потребитель и ему законом не запрещено иметь дома в разных субъектах. Если у него в разных субъектах будут разные УК с одним названием, это тоже как-то нехорошо.
Еще меня интересует что будет если две УК сменят название и оно снова совпадет?
По поводу полномочий  комиссии - полагаю, не исключено, что в случае нехватки полномочий лицензионная комиссия субъекта напишет главному жилищному инспектору страны и он своими повышенными полномочиями спустит расположение аннулировать выданную позднее лицензию согласно такому-то ФЗ. Поэтому лучше не расслабляться по поводу того что дублирующее название в Благовещенске.

Конечно, я точно не знаю как будет и это просто мои спекуляции на тему.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
Стоп, а с чего госпошлина в сумме? Или Вы заплатили пошлину, а при выставлении на взыскание и пошлину включили как возмещение судебных расходов? Тогда пошлину надо начислить в графе пени и судебные расходы в месяце когда выставляли взыскание. А потом полагаю, долг к месяцу где долг был приквитировать, а пени и пошлину к тому месяцу где взыскание выставляли.
Штрафы с 1 января 2018
 
[QUOTE]Andrey_S пишет:
Я все понял верно.[/QUOTE]Честно, в Вас не сомневаюсь, в них сомневаюсь. Каждый месяц делаем сертификаты для какого-то МКУ, с первой попытки почти никогда не проходит - и требования и свои слова специалисты казначейства меняют ну очень часто.
[QUOTE]Andrey_S пишет:
С ГИС ГМП не работал, не в курсе. Запросы из ГИС ЖКХ работают через СМЭВ.[/QUOTE]Ну так я скажу - с ГИС ГМП вообще все организации и органы (кроме казначейства разве что) работают исключительно через СМЭВ. С ГИС ЖКХ доступны личный кабинет, прямые запросы на сервер, а с ГМП нет больше никаких вариантов. Однако в казначействе со своей системой (ГИС ГМП) выборку идентификаторов не сделали, что говорить о чужой (ГИС ЖКХ).
Что с ГИС ЖКХ работают через СМЭВ - понятно. Примерно представлю процесс так: платежи создаются на сервере регионального управления, согласовываются/исполняются, поступают на сервера центрального аппарата, отправляются в СМЭВ, принимаются ГИС ЖКХ. Что СУФД на серверах региональных управлений будет как либо работать со СМЭВ - далеко не факт.[quote:17e7d8xn]Взносы по капитальному ремонту всегда начисляются на собственника. А они тоже подлежат размещению в ГИС ЖКХ. Таким образом на муниципалитет ежемесячно выставляется платежных документов не меньше, чем помещений в муниципальной собственности.[/quote:17e7d8xn]Ясно, но такого потока платежей пока не наблюдаю.
Штрафы с 1 января 2018
 
[QUOTE]Andrey_S пишет:
Запрос выставленных платежных документов из ГИС ЖКХ, как и размещение фактов оплаты в ГИС ЖКХ - работают через сервисы СМЭВ. Казначейство (по крайней мере УФК по Владимирской области) уже размещает факты оплаты в ГИС ЖКХ, но без ГИСовских идентификаторов.[/QUOTE]С этим даже спорить не буду, послать не такая глобальная задача. Однако проблема в выборке данных, потому что данные оплаты изначально формируются на конечном рабочем месте, а сопряжение со СМЭВ находится на серверах центрального аппарата казначейства. И по всей логике работы СУФД скорее напоминает банальную электронную почту чем полноценную информационную систему. По крайней мере, в разных регионах отличаются IP на которые нужно заходить для работы, то есть сервер на котором работают конечные пользователи - это сервер регионального управления казначейства. И нет видимых конечным пользователям механизмов достучаться до центрального аппарата. Адрес может быть и доступен по закрытой сети, но там нужны кже совсем другие логины и пароли.

Поправьте меня если ошибаюсь, но даже про выборку данных из ГИС ГМП (которой само казначейству рулит) в СУФД (казначейство) через СМЭВ я что-то не слышал. Вот такой механизм мог бы послужить "прецедентом" получения идентификаторов из другой ГИС.[QUOTE]Andrey_S пишет:
Особенность в том, что в отличие от клиент-банков для бизнеса, в СУФД сейчас вообще нет спецполей ввода, в которые плательщик мог бы вбить эти идентификаторы для их последующего размещения в ГИС ЖКХ. И по пояснениям представителей нашего УФК этот вопрос сейчас решается на стадии согласования нормативки.[/QUOTE]Насчет спецполей, я полагаю, Вы неправильно поняли представителей УФК: форма заявки на кассовый расход и так очень "плотная", там просто некуда втиснуть еще пару спецполей. Все предыдущие вводы новых идентификаторов за последние годы прошли по схеме "С 1 января 20хх года нужно указывать в ЗКР Код ОКТМО, он будет указываться в поле 105 вместо такого-то кода" - ни разу новых полей не ввели. Поэтому как бы ни хотелось отдельных полей скорее всего итогом согласования нормативки будет указание вносить данные в поля документа-основания платежа. Как говорится, поживем-увидим, но я бы не стал рассчитывать на такую "роскошь" (отдельные спецполя).[QUOTE]Andrey_S пишет:
По поводу автоплатежей - я имел в виду не автосписание средств, а автозаполнение реквизитов документов на оплату (под автоплатежами сейчас, благодаря одноименному сервису Сбербанка для физлиц, обычно понимается именно это).[/QUOTE]Стало яснее, спасибо.[QUOTE]Andrey_S пишет:
Муниципалитеты являются плательщиками по сотням помещений в многоквартирных домах. Реквизиты каждого ПД по этим сотням помещений не то что руками - и чтением штрихкодов накладно набивать. То, что нормально это может работать только через сервис запроса ПД из ГИС ЖКХ (по связанным с плательщиком ЕЛС/ИЖКУ) - очевидно.[/QUOTE]Видимо у нас слишком маленький город такой проблемы не бросается в глаза. В большинстве случаев за муниципальный жилой фонд платят квартиросъемщики, но в принципе понял о чем Вы - у нас есть некоммерческие общественные объединения за помещения которых платит муниципалитет. Однако их у нас не сотни. При каждой оптимизации бюджета их хотят выкинуть, но после слезных просьб оставляют.
Шаблон ПД (платежных документов)
 
[QUOTE]Andrey_S пишет:
Именно пример не сквитированных ПД (их наш областной РКЦ не первый месяц кладет в ГИС ЖКХ уже после того, как я оплачиваю "бумажные" квитанции). Если в личном кабинете теперь перейти к функционалу "Оплатить ЖКУ", то к оплате предлагается только последний несквитированный документ по данному ИЖКУ.[/QUOTE]Окей, случай когда все месяцы несквитированы тоже наверно не подходит. Если последний сквитировать вылезет предпоследний?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 2 минуты 9 секунды:[/COLOR][/SIZE]
[QUOTE]Марина З. пишет:
предположительный сценарий, в котором предполагалось задолженность в ГИС брать из шаблона УО на 1 число, а информацию от банков (и других организаций, принявших платежи) использовать для корректировки с 1 на текущее[/QUOTE]
[QUOTE]Марина З. пишет:
Видимо сценарий поменяли...[/QUOTE]Его и не было, но так бы хотелось выдвинуть такой со стороны УО.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 9 минуты 31 секунды:[/COLOR][/SIZE]
[QUOTE]Шла_мимо пишет:
А как же быть с правом собственника указывать в п/п конкретный желаемый месяц оплаты? При задолженности за весь 2017 год, к примеру, он в платеже укажет в квитанции, что платит за март 2017. ГИС все равно будет закрывать долг сначала января 2017?[/QUOTE]Вы ошибаетесть в том плане, что ГИС теперь будет закрывать долги [B]с конца[/B](декабря, ноябрь, октябрь... февраль, январь), а не с начала (январь, февраль, март.... ноябрь, декабрь) и не всей стопкой, а по одному. Применительно к примеру, человек думает, что платит за март 2017, а ГИС что за декабрь 2017.
Полагаю, ГИС на права начхать. Возможность достать старые ПД остается, так что технически право не нарушено, но по умолчанию предполагается, что все ПД оплачены и сквитированы - получите последний. Это если платить через ГИС, через банк все также потребуется указать период.
Шаблон ПД (платежных документов)
 
[QUOTE]Шла_мимо пишет:
входящее сальдо - на 01.01.18.[/QUOTE]Значит все дело в этом, когда говорите что все совпало, имеете ввиду на 1 число текущего периода, а Hexer, как я понимаю, сравнивает с задолженностью на момент выставления нового счета и говорит что не совпадает. На деле 1с считает одинаково, но мнения противоположные.[QUOTE]Шла_мимо пишет:
Поэтому даже нет разницы - выгружаю я данные 25 или 29 января.[/QUOTE]Вам нет разницы, а ГИСу есть, потому как по логике ГИСа еще надо посчитать задолженность с учетом оплат поступивших с 1 по 25 или с 1 по 29. Что было на 1 число ГИС вообще не интересует. По этому поводу я писал в посте в конце 98 страницы. Способ ГИСа ориентирован на подсчет пени от суммы задолженности за предыдущие периоды. Поэтому неудивительно, что пени не совпадают когда вводите данные не на ту дату, которую ГИС ожидал.[QUOTE]Шла_мимо пишет:
А можно Ваш пост чуть менее "замороченно" перевести?))) То есть при оплатах закрываются сначала предыдущие долги? Или вы о какой-то проверке правильности заполнения шаблонов?[/QUOTE]Так вроде в конце и написано "попроще": выбирается не последний среди всех (декабрь), а последний неквитированный (если декабрь сквитирован полностью, а ноябрь частично сквитирован, то последний неквитированный будет за ноябрь). Впрочем , было бы лучше если бы еще кто-то это подтвердил, вдруг у написавшего в чате какой-то редкий глюк ГИСа. Вдруг проявляется только если декабрь был сквитирован до обновления (до 27-28 января). Даже если редкий, то приятного мало.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 8 минуты 58 секунды:[/COLOR][/SIZE]
[QUOTE]Andrey_S пишет:
Про оплату последнего выставленного платежного документа написано очень однозначно и работает именно так - я проверил на себе. [/QUOTE]Подтвердите, пожалуйста, у Вас все предыдущие также были оплачены (сквитированы) на этот момент? Если да, то у Вас не проблемный случай. Нужно проверить кого-то у кого были несквитированы прошлые месяцы и оплатить только последний. Есть информация, что в таком случае вылезает предыдущий период.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 16 минуты 34 секунды:[/COLOR][/SIZE]
[QUOTE]Andrey_S пишет:
Ни о чем другом в описании этого изменения тоже не говорится.[/QUOTE]Именно поэтому считаю, что изменение несколько однобоко. Один факт исправляют, а что они связан другими - игнорируют.[QUOTE]Andrey_S пишет:
Как раз с оперативностью передачи сведений об оплатах в ГИС ЖКХ у банков дела по большому счету обстоят нормально. ... Кстати, есть банки, которые до сих пор не размещают факты оплаты в ГИС ЖКХ, причем не какие-то мелкие региональные. МИнБ, например.[/QUOTE]Как-то не за то зацепились. Я не имел в виду только исключительно банки (есть еще множество организаций, принимающих платежи) и как они предоставляют в настоящий момент (этот момент тоже не очень отрегулирован - где-то ни банк ни организация не загружают, где-то дублируют информацию) - там был предположительный сценарий, в котором предполагалось задолженность в ГИС брать из шаблона УО на 1 число, а информацию от банков (и других организаций, принявших платежи) использовать для корректировки с 1 на текущее.
Шаблон ПД (платежных документов)
 
[quote:2m57xgrs]@kadykovanp_twitter вчера,19:11
даа. все я вспомнила. у одного коллеги мы оплатили декабрь и он сквитировался. а ноябрь не весь. и сегодня там отражался пд за ноябрь[/quote:2m57xgrs]Из чата разработчиков интеграции. Вообще замечательная реализация "за самый поздний период". Вроде такого похоже:[code:2m57xgrs]select top 1 * from pd where status=0 order by pd_period desc;[/code:2m57xgrs]вместо[code:2m57xgrs]select * from (select top 1 * from pd order by pd_period desc) where status=0;[/code:2m57xgrs]Пояснение: похоже что "оплатил за декабрь? покажем за ноябрь; оплатил и за ноябрь? покажем октябрь". И так далее, пока есть неквитированные ПД.
Штрафы с 1 января 2018
 
[QUOTE]Andrey_S пишет:
[QUOTE]Sergey_P пишет:
хммм у меня жена в бюджете на счетах сидит (в том числе и на коммуналке), думаю, если бы уже вводить начали и казначейство запрашивало, она меня уже терзать начала.[/QUOTE]Нормально казначейские платежи смогут снабжаться идентификаторами ГИС ЖКХ только при условии получения их запросом из самой ГИС ЖКХ. Т.е. при наличии функции автоплатежей по набору ЕЛС/ИЖКУ. Руками такой объем платежек заполнять бессмысленно - и затратно, и ошибок операторы наделают.[/QUOTE]Автоматическое заполнение/автоплатеж - это очень сложный вопрос. Как я понимаю, 1) бюджетные платежи проходят через программное обеспечение СУФД - по криптотоннелю с Казначейством, вставить туда обмен с ГИС ЖКХ будет проблематично на уровне конечного пользователя (разве что сделают какую-нибудь выгрузку из 1с через файл, тогда идентификаторы ГИС ЖКХ надо будет сначала в 1с как-то затащить - то есть еще и доработка конфигурации БГУ потребуется); 2) у Казначейства своя закрытая сеть, в которой ограничен доступ к Интернету, то есть получение данных на серверах Казначейства по обычному криптотуннелю также сложно. То есть это потребует получения данных ГИС ЖКХ через СМЭВ (куда им проще получить доступ) и добавления новых механизмов в СУФД. Итого: слабо верится, что это сделают за ближайший год.

Кроме того, автоплатеж вряд ли возможен - бюджетные лимиты весьма жесткие и часто уходят почти полностью на зарплату, поэтому ЖКУ обычно добирают по субвенциям из вышестоящих бюджетов, а сроки их поступления сложно предугадать. Например, по субсидиям гражданам по ЖКУ (госуслуга, переданная с регионального уровня) сначала прислали 60% от запрошенного на январь текущего года объема субвенции, через неделю в региональном минфине решили, что все не так плохо, выделили денег региональному минсоцразвития и из последнего уже нам написали что "субвенция будет доведена до 100%". Замечу, что субсидии в этом случае платят гражданам, то есть эта госуслуга в гис жкх не попадает, передаются реестры в банки (а в банк вроде бы общей суммой).

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

С ручным заполнение попроще - есть поля документа-основания в заявке на кассовый расход (обычно пустые), есть инструкция идентификатор ГИС ГМП вбивать туда. Поэтому если согласуют в нормативке в качестве допустимого документа идентификатор начисления ГИС ЖКХ, то останется только добавить такой тип документа и отладить корректную передачу данных полей в информации об оплате. Это уже реальнее ждать - полагаю, через месяца так 3 после нормативки.
Шаблон ПД (платежных документов)
 
[QUOTE]Andrey_S пишет:
Вы вероятно об этом?[/QUOTE]Да. Про суммирование вообще ничего не сказано. Однако, разработчики гис столько раз применяют и откатывают исправления, формулируют в описании совсем не то, что хотелось бы прочитать. Например, я бы в таком сообщении хотел бы прочитать еще про суммирование "справочных данных о задолженности" - убрали или нет. Но они об этом упорно молчат. Поэтому даже если разработчики гис написали официально в исправлениях считаю это не более чем уровень "слуха", который еще нужно проверять во всех нюансах. Вдруг другое исправление затерло эти изменения или есть мелкие детали все перечеркивающие.[QUOTE]Шла_мимо пишет:
Выгрузила сейчас обротку за январь по одному МКД из 1С и сформировала там же шаблон платежных документов для загрузки в ГИС. Совпало входящее сальдо (задолженность + авансы) и январские начисления.[/QUOTE]Можно тут поподробнее - совпало сальдо с чем и сальдо на какой период времени - начало месяца или момент начисления?[QUOTE]Шла_мимо пишет:
 Вот я сейчас рассуждаю логически. Со стороны УО так и должно быть: выгружается долг и начисления в личный кабинет плательщика. А банки выгрузят оплату за данный месяц. И чел получит исходящее сальдо, совпадающее в Вашим в учетной системе. ИМХО[/QUOTE]То есть считаете что из УО реальные данные по заложенности, от банков раз в месяц справочные? Ну, если считать что плательщик будет смотреть в ЛК 1 раз в месяц, то можно и так. Это не отменяет необходимости передачи из банка идентификаторов в оплате, но оправданнее на период пока с банками не утрясется.

Но вот идеологи ГИС считают, что прям через пару часов плательщик посмотрит в лк и увидит оплату.  :lol: В этом сценарии банкам придется поторопиться. Кроме того, если банки будут передавать раз в месяц, то ГИС однозначно будет в этот день лежать.
Шаблон ПД (платежных документов)
 
[QUOTE]Hexer пишет:
Нужно выяснить где проблема: неправильные настройки у нас или ошибка разработчиков конфигурации.[/QUOTE]Добрый день! На этот вопрос наверно нужно больше данных для ответа, например, скрины настроек или примеры с обеих сторон как посчитано в 1с.

Ну и конечно договориться о логике - например, если одна сторона считает что 0 правильно и называет 700 ошибкой, а другая считает 700 правильно и говорит что ошибки нет, то при одинаковых настройках и начислениях мнения не сойдутся. Как мне показалось в диалоге было различие в логиках. Прошу считать длинное пояснение про сальдо "за миллисекунду до нового начисления" как попытку выработать некую общую основу что считать за "правильно".

[SIZE=85px][COLOR=greenpt]Отправлено спустя 3 минуты 25 секунды:[/COLOR][/SIZE]
[QUOTE]Форест пишет:
Может пацаны не знают, что у них эти "справочные" поля вполне себе в реальной сумме к оплате участвуют?[/QUOTE]Ходит слух, что после вчерашнего обновления гис лесом посылает старые ПД и изначально выводит только последний период, в котором только одна сумма задолженности. То есть извращенцы от гиса суммирование вроде как не грохнули, но сейчас не с чем суммировать. :lol: Однако некрофаги в ЛК могут вытащить на белый свет и прошлые ПД, тогда возможно просуммируется как и раньше. :shock: Пока не видел подтверждения.
Собственник передал показание ИПУ через Гис
 
Я спрашивал немного про другое)) "Выгрузка" везде в названиях, "выгрузка" (то есть из 1С в гис), а нужна в контексте темы "загрузка" (из гис в 1с). Есть загрузка по показаниям там?
Собственник передал показание ИПУ через Гис
 
[QUOTE]Шла_мимо пишет:
Можно загрузить в 1С номера ИПУ из ГИСа[/QUOTE]А показания?
Штрафы с 1 января 2018
 
[quote:2azgtmem]Ёще одно мнение : "ГИС ЖКХ ПАРАЛИЗУЕТ ПЛАТЕЖИ В ЖКХ".[/quote:2azgtmem]Это вообще наверно тут оффтопик. Больше подходит для темы эмоций по гис жкх. Для себя отметил, что согласился бы только с половиной, но чтобы тут обсуждение не разжигать промолчу с чем именно.
Шаблон ПД (платежных документов)
 
[QUOTE]Hexer пишет:
В шаблон идёт "Задолженность за предыдущие периоды" - 700р. и начисление за декабрь 750р.[/QUOTE]Тут все дело во времени на которое берутся цифры. По логике ГИС похоже надо брать на момент выставления начисления и все станет логически непротиворечиво. Потому что задолженность за прошлые периоды (на момент выставления начисления) не равна сальдо на начало периода, а отличается как раз на внесенные оплаты между началом периода и моментом начисления. Но если взять только этот период "потеряем" оплаты между прошлым начислением и концом месяца. Поэтому "внесено оплаты" - предполагаем период с прошлого начисления до текущего начисления, следовательно "внесено оплаты" Вы уже учитываете в цифре "задолженность за предыдущие периоды". В Вашем примере задолженность за предыдущие периоды должна быть 0, так как за прошлый период было 700 руб и их погасили до момента начисления. Сальдо на начало/конец месяца ГИС по сути не задействует вообще, задействовано сальдо "за миллисекунду до нового начисления" которое идет в поле "задолженность за прошлые периоды".

Если потребитель чуть опоздал с оплатой и на момент начисления прошлый не погашен, то за прошлые задолженность - 700 и за текущий 750 = 1450.

Все портит только то, что ГИС еще и суммирует задолженность за прошлые периоды.
Выгрузка из 1С в ГИС и обратно?
 
Нет, не должно так получиться - в ГИС выгружаете в ПД всю начисленную сумму без учета что кто-то чего-то уплатил, тогда с бумажкой все совпадет. А оплаты когда там банк еще загрузит. Ну а если сами же и оплаты грузите, то грузите оплаты только после ПД иначе выйдет вообще каша с "авансовыми" платежами.

Фактически пока баланс у потребителя в ЛК вообще непонятно как считает. Даже если выверите в своем ЛК сумму до копейки по потребителю, у него будет показывать другую цифру. так что важен сам факт  выгрузки, а не совпадение цифр, валите все на ГИС.
Шаблон ПД (платежных документов)
 
[QUOTE]Шла_мимо пишет:
Но там другой механизм начислений и при выгрузке начислений в шаблон 1С обращается именно к блоку операций по жилым помещениям[/QUOTE]
[QUOTE]Форест пишет:
Мы начисляем на нежилые в общем потоке начислений, а распечатать бумажки какие нужны собственнику, счет, акт, СФ или обычную квитанцию, это не проблема.[/QUOTE]Я тоже считаю, что должно быть в общем потоке - иначе потом получится ерунда с контролем фактов оплаты - что-то должно в бухгалтерию прийти, что-то в абонентский отдел. Если у них разные базы, то все время будут накладки и задержки передачи. Поэтому должна быть тесная интеграция с "бухгалтерской" частью 1С. Заодно это позволит посмотреть реквизиты/инн/снилс плательщиков, а не вбивать несуществующие данные при разделении л/с. Грубо говоря до некоторого предела - чем меньше баз тем лучше, но сложнее настроить всем права, чтобы не вбивали мусор.

Полагаю, не очень будет удобно со справочником контрагентов впихивать ФЛ и ЮЛ, но можно наверно завести какой-нибудь признак типа лица и по нему определять из справочника ФЛ или из справочника ЮЛ выбирать плательщика. Говорю в общем, потому что 1С конфигурацию с ЖКХ я видел только на скриншотах, возможно это уже решено в конфигурации.
[quote:mg1g0pzl] Несколько версий ГИСа назад можно было разместить несколько ПД на 1ЛС - в последней версии я пробовал - это невозможно.[/quote:mg1g0pzl]Печально. Раньше вроде было какое-то условие, не помню точно "в проекте только 1 ПД на л/с" или вроде того, не из-за этого условия не размещает? Может быть что-то осталось в проектах?
Новые требования к протоколам общих собраний МКД в 2019 году
 
[QUOTE]Ильич пишет:
Я так не считаю. На ОСС зарегистрировано 100, значит большинство - 51 и плевать на то, сколько недействительных. Тут хоть ГИС, хоть не ГИС.[/QUOTE]Пожалуй соглашусь, что [U]должно быть[/U] так. Но должно быть и что есть - две большие разницы.

С другой стороны, посмотрите как на выборах - обращали внимание, что несмотря на недействительные бюллетени, а их кое-где бывает 10%, сумма все вариантов должна быть 100%, не 90%, то есть недействительные не считаются при определении процента. А вот явка считается и действительные и недействительные и даже кто унес с собой. Соответственно есть два понятия - принявшие участие в выборах и принявшие участие в голосовании. Получается, пришел на выборы и испортил бюллетень - твой голос разделился пропорционально голосам неиспорченных.Проводя аналогию, допустим в Вашем примере, заменив ОСС выборами, что для того чтобы голосование состоялось должно было прийти минимум 90 и пришло 100 (решение действительно), но так как 20 испортили бюллетени, то большинство стало 41 из 80, но решение не стало недействительным потому что эти 20 пришли и они все равно считаются. Формально недостающие до 51 голоса 10  голосов дали испортившие как половину от своего количества.

Почему Вы считаете, что на выборах это нормально, а на ОСС нет? Может быть, участникам всевозможных голосований пора понять, что прийти и испортить бюллетень - это отказаться от своего голоса в худшей форме чем вообще не прийти, потому что придя Вы еще и кворум добавляете. И соответственно перестать устраивать детский сад с порчей бюллетеней.
Шаблон ПД (платежных документов)
 
Эм, а бухгалтерия на коленке что ли считает без 1С?
Одно помещение - два лицевых счета
 
Поправили в личку, что уже работает - при проставленной галочке создается новый ЕЛС "и ИЖКУ не плодятся". А вот требование паспорта не отменили еще.
#
[QUOTE]Анимаиса пишет:
Сегодня пыталась поработать с ГИС.[/QUOTE]Первый скриншот это ГИС ЖКХ, второй ЕСИА. Не надо к ГИС еще и ошибки ЕСИА списывать, у ГИС и так хватает. :lol:
Хотя конечно мне тоже не особо нравится как реализована ЕСИА - ни назад не тыкнуть, ни на исходную страницу откуда на ЕСИА перекинуло не перейти, приходится или править вручную в строке адреса или из закладок открывать.
#
[quote:2qigls66]Каждая сторона грузит только свои услуги своим ПД со своими реквизитами[/quote:2qigls66]Примечание. Конечно, теоретически, одна организация может добавить реквизиты другой и включить услуги другой организации в ПД, однако там есть заморочки как с реквизитами, так и со связанными данными, например, показаниями ПУ, которые потянут ДРСО и т.д.
#
[QUOTE]andreas_2017 пишет:
Подобная же ситуация. Есть платежный агент, через которого производятся платежи жильцов. При импорте платежных документов из бухгалтерской программы выходит ошибка - несоответствие реквизитов (в ГИС'е у платежного агента указаны реквизиты его, у УО - её реквизиты и указан платёжный агент с реквизитами, размещён договор с платёжным агентом; в импортируемых платежных документах указаны реквизиты платежного агента для проведения платежей). Писал в техподдержку - посоветовали добавить реквизиты платежного агента к своим. Но ведь это по сути не правильно ?[/QUOTE]Да, очень похожая ситуация (за исключением того, что у расчетного центра в ГИС вообще не предполагается прием на свой счет, а у платежного агента допускается, если он сам предоставляет услуги). Как я понял из сообщения, УО пытается импортировать платежные документы в которых реквизиты платежного агента? Это неправильно, укажите в платежных документах реквизиты УО. Добавление реквизитов предназначено для случая, когда в ПД включаются услуги, которые предоставляет другая организация. Если сделать по совету техподдержки, то выйдет, что услуги предоставляет платежный агент, а УО вообще не причем.

Поясню, как я все это понимаю. "у УО ... указан платёжный агент с реквизитами, размещён договор с платёжным агентом": указание платежного агента делается для того чтобы платежный агент смог разместить [B][U]платежи[/U][/B] с указанием реквизитов УО (без этого агент сможет принимать платежи только на свои реквизиты), а не для того чтобы УО могла разместить ПД с реквизитами агента. Другими словами, реквизиты указываются для размещения ПД (например, одна организация размещает услуги в одном ПД за несколько организаций), а платежные агенты и договора указываются для размещения платежей.
Делаем вывод: если в платежах от платежного агента будут указаны конечные реквизиты УО (а именно это подразумевается при указании платежного агента и договора), то в платежных документах, чтобы они сквитировались с такими платежами, также должны быть указаны реквизиты УО.

Если и в ПД и в платежах указаны реквизиты УО, то УО сможет их квитировать как автоматическом, так и в ручном режиме. Разные реквизиты приведут к невозможности квитирования. Если же и в платежных документах и в платежах указаны реквизиты платежного агента и агент не УО/РСО, то ручное квитирование будет невозможно, про автоматическое не могу с уверенностью сказать.

Допустим, платежный агент принимает платежи в кассу, потом сдает на свой счет (но эти операции не отражаются в ГИС), потом переводит на счет УО (это отражается в ГИС, указываются реквизиты конечного получателя - УО). С отражением могут быть проблемы, если платежный агент перечисляет всю сумму за день одним платежем, ведь в ГИС как минимум на каждый ЛС, а лучше на каждый ПД (а ПД может быть на каждую услугу и месяц по одному ЛС) должен быть отдельный платеж на счет УО. Это значит либо переводить кучу мелких платежей и указывать их реальные платежные идентификаторы в ГИС, либо послать одной суммой, но выдумать кучу "виртуальных" идентификаторов платежа при размещении в ГИС.

Немного сложнее случай когда, например, одна организация УО + платежный агент для РСО, вторая организация - РСО + платежный агент для УО. В таком случае, договоры с другой организацией как с платежным агентом предполагаются у обеих сторон. Каждая сторона грузит только свои услуги своим ПД со своими реквизитами, и соответственно размещает платежи за свои услуги на свои реквизиты, платежи за услуги другой организации на реквизиты другой организации.
#
Не понятно при чем здесь расчетный центр и его реквизиты - ведь расчетный центр не предоставляет услуги и ресурсы. В платежке они должны заполнить реквизиты конечного получателя (УО или РСО, например), который предоставляет услуги и ресурсы. Точную ссылку на нормативку не вспомню, но предполагалось, что расчетный центр не должен крутить деньги на своих счетах, а в течение суток перечислять на счет конечного получателя, то есть для ГИС в плане платежей он как бы не существует.

Если заполнить в платежке реквизиты расчетного центра и если расчетный центр сам не УО/РСО до кучи, то сквитировать платежи никто не сможет: у функции расчетного центра нет такого интерфейса, интерфейс есть у конечной организации, но конечная организация не увидит в нем платежи по платежкам с реквизитами расчетного центра. В случае, если конечная организация делегирует полномочия расчетному центру как оператору ИС, то расчетный центр сможет увидеть и сквитировать только те платежки, в которых указаны реквизиты конечной организации, делегировавшей полномочия, но все равно не увидит в ГИС платежи, в которых реквизиты самого расчетного центра (хотя и увидит их на своем счете). Получается, сейчас грузите платежки ради того чтобы грузить, но они всегда будут не квитированы в личном кабинете гражданина.

Если Вы предоставляете услугу и деньги в конечном счете приходят Вам, то Вам нужно делегировать расчетному центру полномочия по выгрузке платежек, а расчетному отправлять платежки от Вашего имени (с Вашими реквизитами), а не от имени расчетного центра. В этом случае, они не увидят деньги на своем счете, но увидят по делегированным полномочиям платежи в ГИС. Короче, они затупили, пытаясь отправить платежки с их реквизитами, еще и Вас в заблуждение ввели. Либо просто хотят крутить деньги на своем счете.
#
Ну а что... добавили поле, закрыли заявку в жире, потом убрали поле и все шито-крыто - заявка то закрыта уже.
#
[QUOTE]Sergey_P пишет:
отчество не является обязательным полем[/QUOTE]Отчество естественно не обязательное, но в файле фамилия 1, имя пусто, отчество 1. Имя все же обязательное поле.
#
исправляют ошибки после исправления ошибок - наверно по большей части откатывают исправления)))
#
1) "счета разделены" = "Да" должно быть только в тех строках где указан номер комнаты (у Вас только пять таких строк). Для таких вроде бы нужно указать снилс или паспортные данные, то есть указывая  "счета разделены" = "Да" и не указывая снилс или паспортные данные вы уже сразу выкидываете все строки в ошибки.
2) ФИО 1 1 1 также весьма интересно, пустое поле имени при заполненном отчестве тоже не очень хорошо. Не уверен, как ГИС на это среагирует, но я бы на месте ГИС на них ругнулся. А как это сработает с признаком разделения - вообще сложно предугадать. Вдруг их потом сведет в одну платежку?
3) почему тип счета "ЛС УО", когда основание "Договор ресурсоснабжения (ЛС РСО или ЛС РЦ)" - что-то тут не так. Этим также выкидываете все строки в ошибки. Если Вы РСО (в том числе, если одновременно и УО и РСО - тогда Вы не можете заключить договор сами с собой и не сможете выстроить цепочку ресурсоснабжения как УО, но сможете трактовать все договора как прямые с РСО) - ставьте ЛС РСО; если Вы РКЦ и хотите выставить единую платежку - ставьте ЛС РЦ; если РКЦ без единой платежки - ждете пока ЛС загрузят УО/РСО и получаете к ним доступ; если Вы УО, но не РСО, то ставьте другое основание. Хотя в случае УО вполне возможно, что счета должны загрузить РСО или РКЦ, а Вам вообще не нужно парится с ЛС. Чтобы сказать точнее нужно больше информации - кто исполнитель, договора какие заключены, в чьей собственности оборудование и т.д.
#
Молодцы, так постепенно и Бурмистр и напишет свою ГИС. qws Классная идея с единой экосистемой, но будет ли востребовано именно начисление неизвестно. Основное сомнение - по поводу интеграции с другими системами. Как минимум потребуется интегрироваться с 1С из-за платежей идущих мимо ГИС и налоговой отчетности. Выше уже сказали про эквайринг, начальную массовую загрузку (ну правда, много ли найдется программистов запилящих выгрузку всех данных из их системы, чтобы от их системы отказались - значит Вам придется эти данные как-то выколупывать из других систем), наверняка еще много чего потребуется чтобы всех удовлетворить.
Второе - сейчас каждая УО и РСО считает по-своему, по форуму это отчетливо видно. Если делать вариант под каждого - получится махина не меньше ГИС, но и подвести всех под один знаменатель тоже непростая задача (некоторые бухгалтеры ну очень уперты и будут считать как привыкли даже если это уже ни с каким законом не совпадает). В этом смысле можно пожелать какой нибудь мастер настроек по вопросам (вроде таких: Вы предоставляете услугу? В чьей собственности бойлеры? Используются прямые договора?) предлагающий варианты расчета.
Третье - "тыдыщ и все сделаем" замечательно, но чем больше функций в системе, тем меньше будет времени у программистов на каждую функцию. С выгрузкой в ГИС тоже как-то легко написали, как будто ГИС завтра начнет работать как положено.
Четвертое - браузер это замечательно, но при расчете будет много персональных данных, так что планируется ли настраивать криптотоннель по ГОСТу для работы? Если да, то будет ли собственный внутренний УЦ или будут использоваться сертификаты аккредитованных УЦ.
Пятое - минус всех "облачных" систем - интернет отрубили и все, приехали.
Итого: наверное нужно реализовать наиболее популярные варианты в полной мере и посмотреть что выйдет.
#
Ради интереса посмотрел у ОМСУ и тоже что-то не вижу функционала.
#
[QUOTE]Шла_мимо пишет:
Программно-то как удалить???? Куда обратиться или на какую кнопку тыкнуть?[/QUOTE]Кнопочку? Мечтать не вредно)))
Во-первых, нужна информационная система. Можно использовать 1С как информационную систему. Обратиться к разработчикам 1С по поводу интеграции с ГИС Вы конечно можете, допустим даже Вам сделают, но скорее всего это будет за отдельные деньги.

Цитирую из чата разработчиков интеграции: "в 1С мертворожденные функции подписания", написавший это делает xml в 1с потом подписывает/отправляет через другую программу, обещал как более-менее отладит взаимодействие взяться за подписание в 1С и поделиться результатом. С учетом что все время что-то меняется, отладит еще не скоро.

Во-вторых, информационную систему нужно зарегистрировать в ГИС и наладить соединение. Сначала надо настроить криптотуннель к серверам ГИС и пройти тестирование, для криптотоннеля и подписания требуется КСКП (сертификат электронной подписи) с указанным классом защиты КС2 (то есть вероятно придется получать новый, если у Вас только КС1). Используете ли реально требования класса защиты КС2 им до лампочки, но в сертификате смотрят. С 1 февраля 2018 года еще нужно отправлять айпи-адреса с которых будете обращаться к ГИС, тестовые сервера теперь не отвечают на запросы пришедшие с "левых" адресов. То есть если у Вас динамический айпи (адрес меняется каждый раз при подключении), то надо будет докупить статический у своего провайдера. Потом добавить своей организации полномочия оператора ИС, подождать пока утвердят. Дать разрешение информационной системе на доступ к данным организации. Тогда может быть что-то сможете делать интеграцией, но не сможете править через личный кабинет.
Если краткое описание не напугало и нужны подробности, спрашивайте в [URL=http://forum.burmistr.ru/viewforum.php?f=147]ветке программистов[/URL].

В-третьих, после всего этого геморроя - оно еще и не работает! Разработчики интеграции жалуются и на отсутствие соединения с серверами ГИС и на долгое нахождение запроса в статусе 1 (принят, но не обработан). Техподдержка рекомендует если запрос висит неделю в статусе 1, забывать про него и отправлять снова.Короче, говорят, проще нанять китайских детей для занесения/архивирования чем пилить интеграцию.
#
[QUOTE]Joli пишет:
управляющая в принципе не сможет работать и обслуживать дома в другом регионе, поэтому вполне допускаю что в субъектах могут существовать уо с одинаковыми названиями[/QUOTE]Допустим, по той же лицензии в другом регионе не сможет, но теоретически получить еще одну лицензию в еще одном регионе что-то помещает? Хорошо, пусть не получит вторую лицензию и не обслуживает в другом регионе, но смешивать то предположительно будет потребитель и ему законом не запрещено иметь дома в разных субъектах. Если у него в разных субъектах будут разные УК с одним названием, это тоже как-то нехорошо.
Еще меня интересует что будет если две УК сменят название и оно снова совпадет?
По поводу полномочий  комиссии - полагаю, не исключено, что в случае нехватки полномочий лицензионная комиссия субъекта напишет главному жилищному инспектору страны и он своими повышенными полномочиями спустит расположение аннулировать выданную позднее лицензию согласно такому-то ФЗ. Поэтому лучше не расслабляться по поводу того что дублирующее название в Благовещенске.

Конечно, я точно не знаю как будет и это просто мои спекуляции на тему.
#
Стоп, а с чего госпошлина в сумме? Или Вы заплатили пошлину, а при выставлении на взыскание и пошлину включили как возмещение судебных расходов? Тогда пошлину надо начислить в графе пени и судебные расходы в месяце когда выставляли взыскание. А потом полагаю, долг к месяцу где долг был приквитировать, а пени и пошлину к тому месяцу где взыскание выставляли.
#
[QUOTE]Andrey_S пишет:
Я все понял верно.[/QUOTE]Честно, в Вас не сомневаюсь, в них сомневаюсь. Каждый месяц делаем сертификаты для какого-то МКУ, с первой попытки почти никогда не проходит - и требования и свои слова специалисты казначейства меняют ну очень часто.
[QUOTE]Andrey_S пишет:
С ГИС ГМП не работал, не в курсе. Запросы из ГИС ЖКХ работают через СМЭВ.[/QUOTE]Ну так я скажу - с ГИС ГМП вообще все организации и органы (кроме казначейства разве что) работают исключительно через СМЭВ. С ГИС ЖКХ доступны личный кабинет, прямые запросы на сервер, а с ГМП нет больше никаких вариантов. Однако в казначействе со своей системой (ГИС ГМП) выборку идентификаторов не сделали, что говорить о чужой (ГИС ЖКХ).
Что с ГИС ЖКХ работают через СМЭВ - понятно. Примерно представлю процесс так: платежи создаются на сервере регионального управления, согласовываются/исполняются, поступают на сервера центрального аппарата, отправляются в СМЭВ, принимаются ГИС ЖКХ. Что СУФД на серверах региональных управлений будет как либо работать со СМЭВ - далеко не факт.[quote:17e7d8xn]Взносы по капитальному ремонту всегда начисляются на собственника. А они тоже подлежат размещению в ГИС ЖКХ. Таким образом на муниципалитет ежемесячно выставляется платежных документов не меньше, чем помещений в муниципальной собственности.[/quote:17e7d8xn]Ясно, но такого потока платежей пока не наблюдаю.
#
[QUOTE]Andrey_S пишет:
Запрос выставленных платежных документов из ГИС ЖКХ, как и размещение фактов оплаты в ГИС ЖКХ - работают через сервисы СМЭВ. Казначейство (по крайней мере УФК по Владимирской области) уже размещает факты оплаты в ГИС ЖКХ, но без ГИСовских идентификаторов.[/QUOTE]С этим даже спорить не буду, послать не такая глобальная задача. Однако проблема в выборке данных, потому что данные оплаты изначально формируются на конечном рабочем месте, а сопряжение со СМЭВ находится на серверах центрального аппарата казначейства. И по всей логике работы СУФД скорее напоминает банальную электронную почту чем полноценную информационную систему. По крайней мере, в разных регионах отличаются IP на которые нужно заходить для работы, то есть сервер на котором работают конечные пользователи - это сервер регионального управления казначейства. И нет видимых конечным пользователям механизмов достучаться до центрального аппарата. Адрес может быть и доступен по закрытой сети, но там нужны кже совсем другие логины и пароли.

Поправьте меня если ошибаюсь, но даже про выборку данных из ГИС ГМП (которой само казначейству рулит) в СУФД (казначейство) через СМЭВ я что-то не слышал. Вот такой механизм мог бы послужить "прецедентом" получения идентификаторов из другой ГИС.[QUOTE]Andrey_S пишет:
Особенность в том, что в отличие от клиент-банков для бизнеса, в СУФД сейчас вообще нет спецполей ввода, в которые плательщик мог бы вбить эти идентификаторы для их последующего размещения в ГИС ЖКХ. И по пояснениям представителей нашего УФК этот вопрос сейчас решается на стадии согласования нормативки.[/QUOTE]Насчет спецполей, я полагаю, Вы неправильно поняли представителей УФК: форма заявки на кассовый расход и так очень "плотная", там просто некуда втиснуть еще пару спецполей. Все предыдущие вводы новых идентификаторов за последние годы прошли по схеме "С 1 января 20хх года нужно указывать в ЗКР Код ОКТМО, он будет указываться в поле 105 вместо такого-то кода" - ни разу новых полей не ввели. Поэтому как бы ни хотелось отдельных полей скорее всего итогом согласования нормативки будет указание вносить данные в поля документа-основания платежа. Как говорится, поживем-увидим, но я бы не стал рассчитывать на такую "роскошь" (отдельные спецполя).[QUOTE]Andrey_S пишет:
По поводу автоплатежей - я имел в виду не автосписание средств, а автозаполнение реквизитов документов на оплату (под автоплатежами сейчас, благодаря одноименному сервису Сбербанка для физлиц, обычно понимается именно это).[/QUOTE]Стало яснее, спасибо.[QUOTE]Andrey_S пишет:
Муниципалитеты являются плательщиками по сотням помещений в многоквартирных домах. Реквизиты каждого ПД по этим сотням помещений не то что руками - и чтением штрихкодов накладно набивать. То, что нормально это может работать только через сервис запроса ПД из ГИС ЖКХ (по связанным с плательщиком ЕЛС/ИЖКУ) - очевидно.[/QUOTE]Видимо у нас слишком маленький город такой проблемы не бросается в глаза. В большинстве случаев за муниципальный жилой фонд платят квартиросъемщики, но в принципе понял о чем Вы - у нас есть некоммерческие общественные объединения за помещения которых платит муниципалитет. Однако их у нас не сотни. При каждой оптимизации бюджета их хотят выкинуть, но после слезных просьб оставляют.
#
[QUOTE]Andrey_S пишет:
Именно пример не сквитированных ПД (их наш областной РКЦ не первый месяц кладет в ГИС ЖКХ уже после того, как я оплачиваю "бумажные" квитанции). Если в личном кабинете теперь перейти к функционалу "Оплатить ЖКУ", то к оплате предлагается только последний несквитированный документ по данному ИЖКУ.[/QUOTE]Окей, случай когда все месяцы несквитированы тоже наверно не подходит. Если последний сквитировать вылезет предпоследний?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 2 минуты 9 секунды:[/COLOR][/SIZE]
[QUOTE]Марина З. пишет:
предположительный сценарий, в котором предполагалось задолженность в ГИС брать из шаблона УО на 1 число, а информацию от банков (и других организаций, принявших платежи) использовать для корректировки с 1 на текущее[/QUOTE]
[QUOTE]Марина З. пишет:
Видимо сценарий поменяли...[/QUOTE]Его и не было, но так бы хотелось выдвинуть такой со стороны УО.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 9 минуты 31 секунды:[/COLOR][/SIZE]
[QUOTE]Шла_мимо пишет:
А как же быть с правом собственника указывать в п/п конкретный желаемый месяц оплаты? При задолженности за весь 2017 год, к примеру, он в платеже укажет в квитанции, что платит за март 2017. ГИС все равно будет закрывать долг сначала января 2017?[/QUOTE]Вы ошибаетесть в том плане, что ГИС теперь будет закрывать долги [B]с конца[/B](декабря, ноябрь, октябрь... февраль, январь), а не с начала (январь, февраль, март.... ноябрь, декабрь) и не всей стопкой, а по одному. Применительно к примеру, человек думает, что платит за март 2017, а ГИС что за декабрь 2017.
Полагаю, ГИС на права начхать. Возможность достать старые ПД остается, так что технически право не нарушено, но по умолчанию предполагается, что все ПД оплачены и сквитированы - получите последний. Это если платить через ГИС, через банк все также потребуется указать период.
#
[QUOTE]Шла_мимо пишет:
входящее сальдо - на 01.01.18.[/QUOTE]Значит все дело в этом, когда говорите что все совпало, имеете ввиду на 1 число текущего периода, а Hexer, как я понимаю, сравнивает с задолженностью на момент выставления нового счета и говорит что не совпадает. На деле 1с считает одинаково, но мнения противоположные.[QUOTE]Шла_мимо пишет:
Поэтому даже нет разницы - выгружаю я данные 25 или 29 января.[/QUOTE]Вам нет разницы, а ГИСу есть, потому как по логике ГИСа еще надо посчитать задолженность с учетом оплат поступивших с 1 по 25 или с 1 по 29. Что было на 1 число ГИС вообще не интересует. По этому поводу я писал в посте в конце 98 страницы. Способ ГИСа ориентирован на подсчет пени от суммы задолженности за предыдущие периоды. Поэтому неудивительно, что пени не совпадают когда вводите данные не на ту дату, которую ГИС ожидал.[QUOTE]Шла_мимо пишет:
А можно Ваш пост чуть менее "замороченно" перевести?))) То есть при оплатах закрываются сначала предыдущие долги? Или вы о какой-то проверке правильности заполнения шаблонов?[/QUOTE]Так вроде в конце и написано "попроще": выбирается не последний среди всех (декабрь), а последний неквитированный (если декабрь сквитирован полностью, а ноябрь частично сквитирован, то последний неквитированный будет за ноябрь). Впрочем , было бы лучше если бы еще кто-то это подтвердил, вдруг у написавшего в чате какой-то редкий глюк ГИСа. Вдруг проявляется только если декабрь был сквитирован до обновления (до 27-28 января). Даже если редкий, то приятного мало.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 8 минуты 58 секунды:[/COLOR][/SIZE]
[QUOTE]Andrey_S пишет:
Про оплату последнего выставленного платежного документа написано очень однозначно и работает именно так - я проверил на себе. [/QUOTE]Подтвердите, пожалуйста, у Вас все предыдущие также были оплачены (сквитированы) на этот момент? Если да, то у Вас не проблемный случай. Нужно проверить кого-то у кого были несквитированы прошлые месяцы и оплатить только последний. Есть информация, что в таком случае вылезает предыдущий период.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 16 минуты 34 секунды:[/COLOR][/SIZE]
[QUOTE]Andrey_S пишет:
Ни о чем другом в описании этого изменения тоже не говорится.[/QUOTE]Именно поэтому считаю, что изменение несколько однобоко. Один факт исправляют, а что они связан другими - игнорируют.[QUOTE]Andrey_S пишет:
Как раз с оперативностью передачи сведений об оплатах в ГИС ЖКХ у банков дела по большому счету обстоят нормально. ... Кстати, есть банки, которые до сих пор не размещают факты оплаты в ГИС ЖКХ, причем не какие-то мелкие региональные. МИнБ, например.[/QUOTE]Как-то не за то зацепились. Я не имел в виду только исключительно банки (есть еще множество организаций, принимающих платежи) и как они предоставляют в настоящий момент (этот момент тоже не очень отрегулирован - где-то ни банк ни организация не загружают, где-то дублируют информацию) - там был предположительный сценарий, в котором предполагалось задолженность в ГИС брать из шаблона УО на 1 число, а информацию от банков (и других организаций, принявших платежи) использовать для корректировки с 1 на текущее.
#
[quote:2m57xgrs]@kadykovanp_twitter вчера,19:11
даа. все я вспомнила. у одного коллеги мы оплатили декабрь и он сквитировался. а ноябрь не весь. и сегодня там отражался пд за ноябрь[/quote:2m57xgrs]Из чата разработчиков интеграции. Вообще замечательная реализация "за самый поздний период". Вроде такого похоже:[code:2m57xgrs]select top 1 * from pd where status=0 order by pd_period desc;[/code:2m57xgrs]вместо[code:2m57xgrs]select * from (select top 1 * from pd order by pd_period desc) where status=0;[/code:2m57xgrs]Пояснение: похоже что "оплатил за декабрь? покажем за ноябрь; оплатил и за ноябрь? покажем октябрь". И так далее, пока есть неквитированные ПД.
#
[QUOTE]Andrey_S пишет:
[QUOTE]Sergey_P пишет:
хммм у меня жена в бюджете на счетах сидит (в том числе и на коммуналке), думаю, если бы уже вводить начали и казначейство запрашивало, она меня уже терзать начала.[/QUOTE]Нормально казначейские платежи смогут снабжаться идентификаторами ГИС ЖКХ только при условии получения их запросом из самой ГИС ЖКХ. Т.е. при наличии функции автоплатежей по набору ЕЛС/ИЖКУ. Руками такой объем платежек заполнять бессмысленно - и затратно, и ошибок операторы наделают.[/QUOTE]Автоматическое заполнение/автоплатеж - это очень сложный вопрос. Как я понимаю, 1) бюджетные платежи проходят через программное обеспечение СУФД - по криптотоннелю с Казначейством, вставить туда обмен с ГИС ЖКХ будет проблематично на уровне конечного пользователя (разве что сделают какую-нибудь выгрузку из 1с через файл, тогда идентификаторы ГИС ЖКХ надо будет сначала в 1с как-то затащить - то есть еще и доработка конфигурации БГУ потребуется); 2) у Казначейства своя закрытая сеть, в которой ограничен доступ к Интернету, то есть получение данных на серверах Казначейства по обычному криптотуннелю также сложно. То есть это потребует получения данных ГИС ЖКХ через СМЭВ (куда им проще получить доступ) и добавления новых механизмов в СУФД. Итого: слабо верится, что это сделают за ближайший год.

Кроме того, автоплатеж вряд ли возможен - бюджетные лимиты весьма жесткие и часто уходят почти полностью на зарплату, поэтому ЖКУ обычно добирают по субвенциям из вышестоящих бюджетов, а сроки их поступления сложно предугадать. Например, по субсидиям гражданам по ЖКУ (госуслуга, переданная с регионального уровня) сначала прислали 60% от запрошенного на январь текущего года объема субвенции, через неделю в региональном минфине решили, что все не так плохо, выделили денег региональному минсоцразвития и из последнего уже нам написали что "субвенция будет доведена до 100%". Замечу, что субсидии в этом случае платят гражданам, то есть эта госуслуга в гис жкх не попадает, передаются реестры в банки (а в банк вроде бы общей суммой).

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

С ручным заполнение попроще - есть поля документа-основания в заявке на кассовый расход (обычно пустые), есть инструкция идентификатор ГИС ГМП вбивать туда. Поэтому если согласуют в нормативке в качестве допустимого документа идентификатор начисления ГИС ЖКХ, то останется только добавить такой тип документа и отладить корректную передачу данных полей в информации об оплате. Это уже реальнее ждать - полагаю, через месяца так 3 после нормативки.
#
[QUOTE]Andrey_S пишет:
Вы вероятно об этом?[/QUOTE]Да. Про суммирование вообще ничего не сказано. Однако, разработчики гис столько раз применяют и откатывают исправления, формулируют в описании совсем не то, что хотелось бы прочитать. Например, я бы в таком сообщении хотел бы прочитать еще про суммирование "справочных данных о задолженности" - убрали или нет. Но они об этом упорно молчат. Поэтому даже если разработчики гис написали официально в исправлениях считаю это не более чем уровень "слуха", который еще нужно проверять во всех нюансах. Вдруг другое исправление затерло эти изменения или есть мелкие детали все перечеркивающие.[QUOTE]Шла_мимо пишет:
Выгрузила сейчас обротку за январь по одному МКД из 1С и сформировала там же шаблон платежных документов для загрузки в ГИС. Совпало входящее сальдо (задолженность + авансы) и январские начисления.[/QUOTE]Можно тут поподробнее - совпало сальдо с чем и сальдо на какой период времени - начало месяца или момент начисления?[QUOTE]Шла_мимо пишет:
 Вот я сейчас рассуждаю логически. Со стороны УО так и должно быть: выгружается долг и начисления в личный кабинет плательщика. А банки выгрузят оплату за данный месяц. И чел получит исходящее сальдо, совпадающее в Вашим в учетной системе. ИМХО[/QUOTE]То есть считаете что из УО реальные данные по заложенности, от банков раз в месяц справочные? Ну, если считать что плательщик будет смотреть в ЛК 1 раз в месяц, то можно и так. Это не отменяет необходимости передачи из банка идентификаторов в оплате, но оправданнее на период пока с банками не утрясется.

Но вот идеологи ГИС считают, что прям через пару часов плательщик посмотрит в лк и увидит оплату.  :lol: В этом сценарии банкам придется поторопиться. Кроме того, если банки будут передавать раз в месяц, то ГИС однозначно будет в этот день лежать.
#
[QUOTE]Hexer пишет:
Нужно выяснить где проблема: неправильные настройки у нас или ошибка разработчиков конфигурации.[/QUOTE]Добрый день! На этот вопрос наверно нужно больше данных для ответа, например, скрины настроек или примеры с обеих сторон как посчитано в 1с.

Ну и конечно договориться о логике - например, если одна сторона считает что 0 правильно и называет 700 ошибкой, а другая считает 700 правильно и говорит что ошибки нет, то при одинаковых настройках и начислениях мнения не сойдутся. Как мне показалось в диалоге было различие в логиках. Прошу считать длинное пояснение про сальдо "за миллисекунду до нового начисления" как попытку выработать некую общую основу что считать за "правильно".

[SIZE=85px][COLOR=greenpt]Отправлено спустя 3 минуты 25 секунды:[/COLOR][/SIZE]
[QUOTE]Форест пишет:
Может пацаны не знают, что у них эти "справочные" поля вполне себе в реальной сумме к оплате участвуют?[/QUOTE]Ходит слух, что после вчерашнего обновления гис лесом посылает старые ПД и изначально выводит только последний период, в котором только одна сумма задолженности. То есть извращенцы от гиса суммирование вроде как не грохнули, но сейчас не с чем суммировать. :lol: Однако некрофаги в ЛК могут вытащить на белый свет и прошлые ПД, тогда возможно просуммируется как и раньше. :shock: Пока не видел подтверждения.
#
Я спрашивал немного про другое)) "Выгрузка" везде в названиях, "выгрузка" (то есть из 1С в гис), а нужна в контексте темы "загрузка" (из гис в 1с). Есть загрузка по показаниям там?
#
[QUOTE]Шла_мимо пишет:
Можно загрузить в 1С номера ИПУ из ГИСа[/QUOTE]А показания?
#
[quote:2azgtmem]Ёще одно мнение : "ГИС ЖКХ ПАРАЛИЗУЕТ ПЛАТЕЖИ В ЖКХ".[/quote:2azgtmem]Это вообще наверно тут оффтопик. Больше подходит для темы эмоций по гис жкх. Для себя отметил, что согласился бы только с половиной, но чтобы тут обсуждение не разжигать промолчу с чем именно.
#
[QUOTE]Hexer пишет:
В шаблон идёт "Задолженность за предыдущие периоды" - 700р. и начисление за декабрь 750р.[/QUOTE]Тут все дело во времени на которое берутся цифры. По логике ГИС похоже надо брать на момент выставления начисления и все станет логически непротиворечиво. Потому что задолженность за прошлые периоды (на момент выставления начисления) не равна сальдо на начало периода, а отличается как раз на внесенные оплаты между началом периода и моментом начисления. Но если взять только этот период "потеряем" оплаты между прошлым начислением и концом месяца. Поэтому "внесено оплаты" - предполагаем период с прошлого начисления до текущего начисления, следовательно "внесено оплаты" Вы уже учитываете в цифре "задолженность за предыдущие периоды". В Вашем примере задолженность за предыдущие периоды должна быть 0, так как за прошлый период было 700 руб и их погасили до момента начисления. Сальдо на начало/конец месяца ГИС по сути не задействует вообще, задействовано сальдо "за миллисекунду до нового начисления" которое идет в поле "задолженность за прошлые периоды".

Если потребитель чуть опоздал с оплатой и на момент начисления прошлый не погашен, то за прошлые задолженность - 700 и за текущий 750 = 1450.

Все портит только то, что ГИС еще и суммирует задолженность за прошлые периоды.
#
Нет, не должно так получиться - в ГИС выгружаете в ПД всю начисленную сумму без учета что кто-то чего-то уплатил, тогда с бумажкой все совпадет. А оплаты когда там банк еще загрузит. Ну а если сами же и оплаты грузите, то грузите оплаты только после ПД иначе выйдет вообще каша с "авансовыми" платежами.

Фактически пока баланс у потребителя в ЛК вообще непонятно как считает. Даже если выверите в своем ЛК сумму до копейки по потребителю, у него будет показывать другую цифру. так что важен сам факт  выгрузки, а не совпадение цифр, валите все на ГИС.
#
[QUOTE]Шла_мимо пишет:
Но там другой механизм начислений и при выгрузке начислений в шаблон 1С обращается именно к блоку операций по жилым помещениям[/QUOTE]
[QUOTE]Форест пишет:
Мы начисляем на нежилые в общем потоке начислений, а распечатать бумажки какие нужны собственнику, счет, акт, СФ или обычную квитанцию, это не проблема.[/QUOTE]Я тоже считаю, что должно быть в общем потоке - иначе потом получится ерунда с контролем фактов оплаты - что-то должно в бухгалтерию прийти, что-то в абонентский отдел. Если у них разные базы, то все время будут накладки и задержки передачи. Поэтому должна быть тесная интеграция с "бухгалтерской" частью 1С. Заодно это позволит посмотреть реквизиты/инн/снилс плательщиков, а не вбивать несуществующие данные при разделении л/с. Грубо говоря до некоторого предела - чем меньше баз тем лучше, но сложнее настроить всем права, чтобы не вбивали мусор.

Полагаю, не очень будет удобно со справочником контрагентов впихивать ФЛ и ЮЛ, но можно наверно завести какой-нибудь признак типа лица и по нему определять из справочника ФЛ или из справочника ЮЛ выбирать плательщика. Говорю в общем, потому что 1С конфигурацию с ЖКХ я видел только на скриншотах, возможно это уже решено в конфигурации.
[quote:mg1g0pzl] Несколько версий ГИСа назад можно было разместить несколько ПД на 1ЛС - в последней версии я пробовал - это невозможно.[/quote:mg1g0pzl]Печально. Раньше вроде было какое-то условие, не помню точно "в проекте только 1 ПД на л/с" или вроде того, не из-за этого условия не размещает? Может быть что-то осталось в проектах?
#
[QUOTE]Ильич пишет:
Я так не считаю. На ОСС зарегистрировано 100, значит большинство - 51 и плевать на то, сколько недействительных. Тут хоть ГИС, хоть не ГИС.[/QUOTE]Пожалуй соглашусь, что [U]должно быть[/U] так. Но должно быть и что есть - две большие разницы.

С другой стороны, посмотрите как на выборах - обращали внимание, что несмотря на недействительные бюллетени, а их кое-где бывает 10%, сумма все вариантов должна быть 100%, не 90%, то есть недействительные не считаются при определении процента. А вот явка считается и действительные и недействительные и даже кто унес с собой. Соответственно есть два понятия - принявшие участие в выборах и принявшие участие в голосовании. Получается, пришел на выборы и испортил бюллетень - твой голос разделился пропорционально голосам неиспорченных.Проводя аналогию, допустим в Вашем примере, заменив ОСС выборами, что для того чтобы голосование состоялось должно было прийти минимум 90 и пришло 100 (решение действительно), но так как 20 испортили бюллетени, то большинство стало 41 из 80, но решение не стало недействительным потому что эти 20 пришли и они все равно считаются. Формально недостающие до 51 голоса 10  голосов дали испортившие как половину от своего количества.

Почему Вы считаете, что на выборах это нормально, а на ОСС нет? Может быть, участникам всевозможных голосований пора понять, что прийти и испортить бюллетень - это отказаться от своего голоса в худшей форме чем вообще не прийти, потому что придя Вы еще и кворум добавляете. И соответственно перестать устраивать детский сад с порчей бюллетеней.
#
Эм, а бухгалтерия на коленке что ли считает без 1С?
#
Поправили в личку, что уже работает - при проставленной галочке создается новый ЕЛС "и ИЖКУ не плодятся". А вот требование паспорта не отменили еще.

Для улучшения работы сайта и его взаимодействие с пользователями мы используем файлы cookie. Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Вы всегда можете отключить файлы cookie в настройках браузера.

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

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