new_year

До бесплатного семинара в Москве осталось

  • 2
  • 3
дня

До бесплатного семинара в Самаре осталось

  • 2
  • 1
день

Форум

ГлавнаяГИС ЖКХ: квитирование

ГИС ЖКХ: квитирование

RSS
ГИС ЖКХ: квитирование
 
Цитата
Andrey_S пишет:
Вы были бы правы для гипотетической ситуации, в которой сами поставщики ЖКУ действуют добросовестно. А в жизни это не всегда так, далеко не всегда.
Я работаю в сфере ЖКХ уже 10 лет - с 2008 года. Мои клиенты - несколько УК и десятки ТСЖ, а также один небольшой РЦ. (Сейчас - около 30 тыс. ЛС). Все счета-квитанции (ПД) рассчитывает моя программа. Выставить ПД "недобросовестно" моим клиентам довольно сложно. Да они в этом и не очень заинтересованы. Наоборот, они боятся жалоб жильцов, проверок и штрафов ГЖИ и прочих контролирующих органов. Программа установлена в бухгалтериях клиентов, сам я за них ничего не рассчитываю. Хотя супруга "ведёт" несколько ТСЖ дома сама. Ник здесь - Анимаиса. :-)
Цитата
Andrey_S пишет:
Технически Вас система в этом никак не ограничивает.
Спасибо, Андрей! Пригодится, если всё-таки придётся заняться квитированием в ГИСе.

Отправлено спустя 7 минуты 51 секунды:
Цитата
Sergey Cheban пишет:
Если в "январском" ПД найдётся ошибка, то пени станут меньше.
Смотря какая ошибка. ;-) Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)
 
Цитата
Технически Вас система в этом никак не ограничивает.
Ничего себе. Интересно надолго ли такое продлится.
Цитата
можно ли сторнировать платежи
Все верно, для поставщика ЖКУ проще и правильнее через квитирование "перекидывать". Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить. Насчет шаблонов точно не скажу, но по soap точно есть - многие матерятся потому что исправленные и аннулированные платежи надо выискивать по гису, а условия отбора "недружелюбные" - условие по дате есть, но применяется оно к дате создания платежа. У аннулированного/измененного платежа дата создания естественно не изменяется, то есть приходится все что было запросить снова, а там может будет 1 такой платеж с указанной датой изменения из миллиона. Обещали сделать фильтр по статусу (изменен/аннулирован), но не знаю сделали ли.

В случае приема платежа в кассу самой УК, у УК будет возможность отредактировать существующий платеж в ГИС либо аннулировать платеж в ГИС и загрузить новый вариант платежа (так как насовсем аннулировать и не вернуть деньги потребителю= неразмещению) с исправленным лицевым счетом или периодом оплаты (хотя тут как раз то из-за чего банки платежи не правят - потребитель может потом потрясти бумажкой где указывал май и счет 4, затем возмутиться почему указан март и счет 5, однако если потребитель не указывал их изначально либо написал заявление на изменение, то проблемы нет). Есть еще баги с "отквитированием" при аннулировании платежа.

Если минусы не пугают, то технически возможно "собственную систему квитирования" перенести в ГИС через такие исправления-аннулирования-создания. В конце концов, никто не запрещает вместо 500 рублей в одном платеже, заплатить в один день 5 платежей по сотне. По реквизитам можно подобрать так, чтобы платежи автоквитировались в ГИС только когда нужно и не возиться с их отквитированием.

Грубый теоретический пример: был платеж 500 руб. (авансовый) без месяца, задолженность 0. Через месяц начислили 100, исправили сумму 500 на 400 + создали новый платеж на 100 (начисленную сумму) с конкретным месяцем (дата = дате первоначального платежа), сотенки автосквитировались; повторили еще 3 раза; последний раз создание нового не нужно - только месяц дописать.

Естественно такая схема возможно только при приеме денег самой УК и должна поддерживаться системой учета чтобы можно было однозначно соотнести платежи в гис и платежи в системе учета.
Алгоритм выбора платежа для соотнесения с начисленным месяцем конечно усложнится. Желательно завести 2 поля месяца: одно рабочее, "указанное системой учета" (пустое для авансовых, заполненное для "псевдосквитированных"), другое справочное, "указанное потребителем" (пустое, если потребитель не указал месяца, заполненное, если указал).

Если потребитель указал, то это значение должно быть скопировано в рабочее при наступлении момента начисления за указанный месяц. Потом определить начисленную за месяц сумму и начать выбор платежей на "псевдоквитирование" этой суммы. Сначала выбрать платежи с указанным потребителем месяцем. Если их больше чем нужно, у лишних рабочее значение месяца очищается. Если указанных потребителем недостаточно, то из неуказанных потребителем (с пустым справочным) выбрать несоотнесенные (с пустым рабочим) и выбрать из них на недостающую сумму (допустим самые давние), соотнести (указать месяц в рабочее, отразится в гис исправлением платежа с указанием месяца). При избытке набранной суммы разбить платеж (отразится в гис уменьшением суммы и созданием нового платежа с той же датой на остаток суммы). Если у разбиваемого платежа был указан месяц потребителем, остаточный создается без указанного месяца. Ещё наверно при разбиении у нового указывать в дополнительное поле id первоначального. Как-то так наверно?

Отправлено спустя 14 минуты 43 секунды:
Впрочем схема неустойчива к изменению начисленного.
Цитата
AlcorVol пишет:
Смотря какая ошибка. Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)
Головоломка еще та.
 
Цитата
two_oceans пишет:
Ничего себе. Интересно надолго ли такое продлится.
Надолго. Иначе не было бы возможности квитирования (ручного) фактов оплаты с неуказанными или некорректно (например, с мусорными символами) идентификаторами. На сегодняшний день такой вопрос "наверху" даже не ставится.
Цитата
two_oceans пишет:
Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить.
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).
 
Сейчас подходим к более заковыристым случаям:
- квитированию ПД с пенями (сегодня первый раз такие выставляем через ГИС);
- квитированию ПД с отрицательной суммой документа (образованной в результате перерасчетов, такие примеры еще просто не анализировали).
Кто-то уже проходил? Есть чем поделиться?
 
Цитата
Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

Отправлено спустя 8 минуты 9 секунды:
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
 
Цитата
two_oceans пишет:
В общем случае - конечно проблематично с таким недоделанным контролем целостности.
Почему недоделанным? Мы не ощущаем в этом проблемы (на сегодняшний день, по крайней мере). В норме не возникает потребности аннулирования размещенных платежей, это очень редкие случаи.

Отправлено спустя 10 минуты 19 секунды:
Цитата
two_oceans пишет:
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Да, это штатный случай.

Цитата
two_oceans пишет:

Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов. Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат. Возникает задача "взаимозачетов" при квитировании, это слабое место ГИС ЖКХ. Как и оплаты с авансами и тем более возвраты по ним.
 
Цитата
Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.
Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Цитата
Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.
Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
 
Цитата
two_oceans пишет:
Частично соглашусь.

Не соглашусь. В ПД может быть много разных сумм, в том числе и отрицательных, например "исходящее сальдо", "сальдо расчетов" и проч.. Но если речь идет о графе "сумма к оплате", то она отрицательной быть никак не может.
 
Цитата
two_oceans пишет:
Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Цитата
portal-gkh пишет:
Но если речь идет о графе "сумма к оплате", то она отрицательной быть никак не может.
Со стороны ГИС ЖКХ препятствий нет.
Допускаю, конечно, что такое размещение ПД ошибочно, но не уверен. Понять это точно можно только разобравшись с их квитированием. Поэтому и спрашиваю, кто-то такое проходил?
 
С квитируются пеней, кстати, все нормально - автоматом проходит. Пока, по крайней мере
 
Цитата
two_oceans пишет:
Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Всё обстоит как раз наоборот. :-) Я сам подавал "сумму к оплате" в таких случаях как "ноль". Но ГИС потребовал поставить отрицательную.
 
Цитата
AlcorVol пишет:
Цитата
two_oceans пишет:
Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Всё обстоит как раз наоборот. :-) Я сам подавал "сумму к оплате" в таких случаях как "ноль". Но ГИС потребовал поставить отрицательную.

В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
 
Цитата
portal-gkh пишет:
В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
Мы отталкивались от того, что сообщаем потребителю в бумажном ПД. Там у нас отрицательные суммы, если он получаются при расчете, выводятся (и сумма за период, и сумма с учетом задолженности/переплаты). Мне кажется и неправильно их обнулять - они информируют потребителя о размере образовавшегося долга поставщика ЖКУ перед ним. А вдруг это последний ПД, выставленный этому потребителю (при окончании срока/расторжении договора, например)?
 
Сейчас вебинар начался, в том числе тема квитирования будет затронута
 
Цитата
Andrey_S пишет:
Цитата
portal-gkh пишет:
В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
Мы отталкивались от того, что сообщаем потребителю в бумажном ПД. Там у нас отрицательные суммы, если он получаются при расчете, выводятся (и сумма за период, и сумма с учетом задолженности/переплаты). Мне кажется и неправильно их обнулять - они информируют потребителя о размере образовавшегося долга поставщика ЖКУ перед ним. А вдруг это последний ПД, выставленный этому потребителю (при окончании срока/расторжении договора, например)?

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

это почитайте https://forum.burmistr.ru/viewtopic.php?f=133&t=7835
#91
0 0
Цитата
Andrey_S пишет:
Вы были бы правы для гипотетической ситуации, в которой сами поставщики ЖКУ действуют добросовестно. А в жизни это не всегда так, далеко не всегда.
Я работаю в сфере ЖКХ уже 10 лет - с 2008 года. Мои клиенты - несколько УК и десятки ТСЖ, а также один небольшой РЦ. (Сейчас - около 30 тыс. ЛС). Все счета-квитанции (ПД) рассчитывает моя программа. Выставить ПД "недобросовестно" моим клиентам довольно сложно. Да они в этом и не очень заинтересованы. Наоборот, они боятся жалоб жильцов, проверок и штрафов ГЖИ и прочих контролирующих органов. Программа установлена в бухгалтериях клиентов, сам я за них ничего не рассчитываю. Хотя супруга "ведёт" несколько ТСЖ дома сама. Ник здесь - Анимаиса. :-)
Цитата
Andrey_S пишет:
Технически Вас система в этом никак не ограничивает.
Спасибо, Андрей! Пригодится, если всё-таки придётся заняться квитированием в ГИСе.

Отправлено спустя 7 минуты 51 секунды:
Цитата
Sergey Cheban пишет:
Если в "январском" ПД найдётся ошибка, то пени станут меньше.
Смотря какая ошибка. ;-) Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)
#92
0 0
Цитата
Технически Вас система в этом никак не ограничивает.
Ничего себе. Интересно надолго ли такое продлится.
Цитата
можно ли сторнировать платежи
Все верно, для поставщика ЖКУ проще и правильнее через квитирование "перекидывать". Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить. Насчет шаблонов точно не скажу, но по soap точно есть - многие матерятся потому что исправленные и аннулированные платежи надо выискивать по гису, а условия отбора "недружелюбные" - условие по дате есть, но применяется оно к дате создания платежа. У аннулированного/измененного платежа дата создания естественно не изменяется, то есть приходится все что было запросить снова, а там может будет 1 такой платеж с указанной датой изменения из миллиона. Обещали сделать фильтр по статусу (изменен/аннулирован), но не знаю сделали ли.

В случае приема платежа в кассу самой УК, у УК будет возможность отредактировать существующий платеж в ГИС либо аннулировать платеж в ГИС и загрузить новый вариант платежа (так как насовсем аннулировать и не вернуть деньги потребителю= неразмещению) с исправленным лицевым счетом или периодом оплаты (хотя тут как раз то из-за чего банки платежи не правят - потребитель может потом потрясти бумажкой где указывал май и счет 4, затем возмутиться почему указан март и счет 5, однако если потребитель не указывал их изначально либо написал заявление на изменение, то проблемы нет). Есть еще баги с "отквитированием" при аннулировании платежа.

Если минусы не пугают, то технически возможно "собственную систему квитирования" перенести в ГИС через такие исправления-аннулирования-создания. В конце концов, никто не запрещает вместо 500 рублей в одном платеже, заплатить в один день 5 платежей по сотне. По реквизитам можно подобрать так, чтобы платежи автоквитировались в ГИС только когда нужно и не возиться с их отквитированием.

Грубый теоретический пример: был платеж 500 руб. (авансовый) без месяца, задолженность 0. Через месяц начислили 100, исправили сумму 500 на 400 + создали новый платеж на 100 (начисленную сумму) с конкретным месяцем (дата = дате первоначального платежа), сотенки автосквитировались; повторили еще 3 раза; последний раз создание нового не нужно - только месяц дописать.

Естественно такая схема возможно только при приеме денег самой УК и должна поддерживаться системой учета чтобы можно было однозначно соотнести платежи в гис и платежи в системе учета.
Алгоритм выбора платежа для соотнесения с начисленным месяцем конечно усложнится. Желательно завести 2 поля месяца: одно рабочее, "указанное системой учета" (пустое для авансовых, заполненное для "псевдосквитированных"), другое справочное, "указанное потребителем" (пустое, если потребитель не указал месяца, заполненное, если указал).

Если потребитель указал, то это значение должно быть скопировано в рабочее при наступлении момента начисления за указанный месяц. Потом определить начисленную за месяц сумму и начать выбор платежей на "псевдоквитирование" этой суммы. Сначала выбрать платежи с указанным потребителем месяцем. Если их больше чем нужно, у лишних рабочее значение месяца очищается. Если указанных потребителем недостаточно, то из неуказанных потребителем (с пустым справочным) выбрать несоотнесенные (с пустым рабочим) и выбрать из них на недостающую сумму (допустим самые давние), соотнести (указать месяц в рабочее, отразится в гис исправлением платежа с указанием месяца). При избытке набранной суммы разбить платеж (отразится в гис уменьшением суммы и созданием нового платежа с той же датой на остаток суммы). Если у разбиваемого платежа был указан месяц потребителем, остаточный создается без указанного месяца. Ещё наверно при разбиении у нового указывать в дополнительное поле id первоначального. Как-то так наверно?

Отправлено спустя 14 минуты 43 секунды:
Впрочем схема неустойчива к изменению начисленного.
Цитата
AlcorVol пишет:
Смотря какая ошибка. Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)
Головоломка еще та.
#93
0 0
Цитата
two_oceans пишет:
Ничего себе. Интересно надолго ли такое продлится.
Надолго. Иначе не было бы возможности квитирования (ручного) фактов оплаты с неуказанными или некорректно (например, с мусорными символами) идентификаторами. На сегодняшний день такой вопрос "наверху" даже не ставится.
Цитата
two_oceans пишет:
Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить.
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).
#94
0 0
Сейчас подходим к более заковыристым случаям:
- квитированию ПД с пенями (сегодня первый раз такие выставляем через ГИС);
- квитированию ПД с отрицательной суммой документа (образованной в результате перерасчетов, такие примеры еще просто не анализировали).
Кто-то уже проходил? Есть чем поделиться?
#95
0 0
Цитата
Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

Отправлено спустя 8 минуты 9 секунды:
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
#96
0 0
Цитата
two_oceans пишет:
В общем случае - конечно проблематично с таким недоделанным контролем целостности.
Почему недоделанным? Мы не ощущаем в этом проблемы (на сегодняшний день, по крайней мере). В норме не возникает потребности аннулирования размещенных платежей, это очень редкие случаи.

Отправлено спустя 10 минуты 19 секунды:
Цитата
two_oceans пишет:
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Да, это штатный случай.

Цитата
two_oceans пишет:

Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов. Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат. Возникает задача "взаимозачетов" при квитировании, это слабое место ГИС ЖКХ. Как и оплаты с авансами и тем более возвраты по ним.
#97
0 0
Цитата
Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.
Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Цитата
Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.
Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
#98
0 0
Цитата
two_oceans пишет:
Частично соглашусь.

Не соглашусь. В ПД может быть много разных сумм, в том числе и отрицательных, например "исходящее сальдо", "сальдо расчетов" и проч.. Но если речь идет о графе "сумма к оплате", то она отрицательной быть никак не может.
#99
0 0
Цитата
two_oceans пишет:
Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Цитата
portal-gkh пишет:
Но если речь идет о графе "сумма к оплате", то она отрицательной быть никак не может.
Со стороны ГИС ЖКХ препятствий нет.
Допускаю, конечно, что такое размещение ПД ошибочно, но не уверен. Понять это точно можно только разобравшись с их квитированием. Поэтому и спрашиваю, кто-то такое проходил?
#100
0 0
С квитируются пеней, кстати, все нормально - автоматом проходит. Пока, по крайней мере
#101
0 0
Цитата
two_oceans пишет:
Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Всё обстоит как раз наоборот. :-) Я сам подавал "сумму к оплате" в таких случаях как "ноль". Но ГИС потребовал поставить отрицательную.
#102
0 0
Цитата
AlcorVol пишет:
Цитата
two_oceans пишет:
Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
Всё обстоит как раз наоборот. :-) Я сам подавал "сумму к оплате" в таких случаях как "ноль". Но ГИС потребовал поставить отрицательную.

В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
#103
0 0
Цитата
portal-gkh пишет:
В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
Мы отталкивались от того, что сообщаем потребителю в бумажном ПД. Там у нас отрицательные суммы, если он получаются при расчете, выводятся (и сумма за период, и сумма с учетом задолженности/переплаты). Мне кажется и неправильно их обнулять - они информируют потребителя о размере образовавшегося долга поставщика ЖКУ перед ним. А вдруг это последний ПД, выставленный этому потребителю (при окончании срока/расторжении договора, например)?
#104
0 0
Сейчас вебинар начался, в том числе тема квитирования будет затронута
#105
0 0
Цитата
Andrey_S пишет:
Цитата
portal-gkh пишет:
В ГИСе много разных полей с суммами. Для квитирования важна сумма в поле "Сумма к оплате за расчетный период", т. к. именно она участвует в квитировании. Если сумма отрицательная, документ разместить можно, ГИС препятствовать не будет, но в квитировании он участвовать не должен (корректно сквитировать его не получится). Поэтому, указана отрицательная сумма или ноль с точки зрения квитирования без разницы.
Сумма в поле "Итого к оплате за расчетный период c учетом задолженности/переплаты, руб" не участвует в квитировнии, поэтому тем более без разницы, ноль там или минус. Единственно, при указании нуля вместо минуса ГИС может выдавать предупреждения, типа "значение не совпадает с автоматически расчитанным", которые мы благополучно игнорируем.
Мы отталкивались от того, что сообщаем потребителю в бумажном ПД. Там у нас отрицательные суммы, если он получаются при расчете, выводятся (и сумма за период, и сумма с учетом задолженности/переплаты). Мне кажется и неправильно их обнулять - они информируют потребителя о размере образовавшегося долга поставщика ЖКУ перед ним. А вдруг это последний ПД, выставленный этому потребителю (при окончании срока/расторжении договора, например)?

Мы включаем в бумажный ПД дополнительную информацию, в том числе информацию о текущем состоянии расчетов с потребителем, где указывается сумма задолженности УК перед потребителем (при наличии). К сожалению, в ГИС ПД сделаны по образу и подобию утвержденной примерной формы, где такой информации нет. В любом случае, мы стараемся обеспечить соответствие сумм в полях своих бумажных ПД и ПД, размещенных в ГИСе.
#106
0 0
Здравствуйте! Все ли квитируют ПД на ГИС? Как не пытаюсь, ничего схожего с ПД из программы не выходит((( Никак он не хочет учитывать переплаты, бывшие задолженности.
Неужели у кого-то удаётся ежемесячно квитировать на ГИС как и в бумажном документе??
#107
0 0
Добрый день !
Подскажите пожалуйста кто квитировал платежи ??? И вообще есть за это ответственность ?
#108
0 0
Цитата
KurietsAN пишет:
Добрый день !
Подскажите пожалуйста кто квитировал платежи ??? И вообще есть за это ответственность ?

это почитайте https://forum.burmistr.ru/viewtopic.php?f=133&t=7835
Сейчас на форуме: 6 пользователей
6 пользователей сейчас на форуме

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

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