sanyadnepr

Включение режима высокой продуктивности никак не влияет на отсутствие проверки payID, платеж с одинаковым payID зачисляется на счет абоненту.

Используется https://github.com/nightflyza/Ubilling/blob/master/docs/openpayz/frontend/city24_multi/index.php посмотреть нет проблем, в коде не силен. не смотря на ответ <result>0</result> платеж с одинаковым payID вносится еще раз в базу, вероятней всего проверки нет. Описание что проверить надо по payID не вижу есть ли проверка в коде, поэтому и уточняю. Если вы разбираетесь в коде подскажите пожалуйста есть проверка по payID или нет? Вижу что есть информация о платеже transactionID но payID одинаковый и нет о нем информации. if (pltz_CheckTransaction($extTransactionID

С базой все ОК. OP_HIGHLOAD_ENABLE это понятно, меня интересует проверка по payID есть или нет в модуле для сити24? Array ( [id] => 5648 [hash] => PLTZ_5648 [date] => 2024-02-25 12:00:00 [summ] => 100 [customerid] => 0001 [paysys] => CITY24M [processed] => 1 [note] => transactionID:8938030549 amount:10000 )

Что это некорректно сити24 шлет запрос, но они объясняют что эта ситуация учтена в протоколе и мы не отправляем ответ, хотя отправляем. Самый главный вопрос, проверяется ли payID в модуле? и если платеж с таким payID уже был обработан и внесен в базу почему следующий одинаковый payID далее заносится в базу платеж и пополняется счет абоненту.

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

Приветствую всех. Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно. Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получи

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

Покупай микротик, шишки надо набивать на своем опыте. ))) В гугле забанили? Бери у кайота он херню не предлагает.

Он тебе возможно напишет, но... Готов наступить на грабли? Это не про него...

У тебя опять что то сломалось? Пиши если что.

Так ты тоже согласно букве закона не используешь ЭЭ когда ее нет от постачальныка, но есть из альтернативных источников? Не весели, весь прям в белом и на коне? Не путай провода/линии связи без договоров на столбах и питание оборудки в многоэтажках. Еще раз, никто не оспаривает что договора необходимы, мне еще не приходилось что сначала договора с облами а потом устанавливается оборудование в многоэтажках, обычно все наоборот, сначала оборудование, потом договора с облами.

Ты когда нибудь видел разговор подкованного юриста с облами, которые сразу превращаются в зайчиков?

Платит ОСББ. А ОСББ никто за ээ не платит. Есть конечно и другие варианты, но за рамками этой темы. Хорошо что его вспомнил, у него была одна ошибка, он вместо того чтоб "бороться" на "стенде" (каком то зарезервированном или не критически важном участке сети), "боролся" там где не надо. Никто не оспаривает что необходимы договора с облами, если ты вдруг не понял. Оспаривается "всеобъемлемое право облов" делать все что им захочется.

Тебе плохо? ОСББ никто не платит за ээ. Максимум что можно платить ОСББ за аренду чего то там. Даже за распределение ОСББ ничего не получает. Это в основной массе, кроме всяких там модных ЖК.

Читал и тебе советую почитать.)

Смешались у тебя люди и кони, постачальнык и распределение, потребитель. Не в обоюдном, распределительная сеть многоэтажки на балансе и в собственности балансодержателя многоэтажки, трех-сторонний договор как раз и распределяет где чья ЗО, на входных клеммах РЩ обл, дальше вплоть до входных клемм счетчика ЗО балансодержателя и обл тут никаким боком, проверить/посмотреть он то конечно может если вдруг жалоба/пiдозра на безучетное, счетчик собственность может быть чья угодно но ЗО обла, после счетчика ЗО потребителя и обл тут тоже полем лесом. В отличии от куинку и пона влан на абон

Мафы и кабель с подвала на мафы это уже немножко другое. Но если по тихому, незаметно и не на долго то можно.)) Балансе или собственности? Впрочем даже будь они в собственности обла, у него не появляется право что бы то нибыло делать в щитовой, кроме операции снять/поставить счетчик по согласованию с балансодержателем. Полагаю те страшилки что тобой написаны инициировались "ЖЕК_ом" "ОК" и подобными компаниями на балансе которых эти дома, а не облами. Опять же "под шумок" никто не отменял.

Вполне рабочий бомж-вариант.

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

Может совсем нерасторопный или вообще не бекапил узлы последней мили, бывает. Мой опыт во время постоянных отключений показал что иногда раньше умирали Аплинки хоть и не на долго но все же, если ты не включен "напрямую" в ДЦ и похер на основе чего у тебя построена сеть и какой бекап по питанию. КС например на сколько мне известно не бекапит по питанию домашний инет, всем похер. На пон перешло некоторое количество людей которым очень нужен инет, но и пон не панацея, старлинк выручал в те пару часов что небыло инета, но старлинк обывателю не нужен. А сколько было попалено онушек во в

Обленерго похер.

Согласен куинку отличная тема. Твой текст выше применим в основном когда плотность абонентов и провайдеров зашкаливает. Страхи из прошлого про одинаковые маки сильно преувеличены, это диагностируется достаточно оперативно. Можно и без привязки по маку идентифицировать абона плюс по логину паролю в ЛК активация и тоже втыкнул что угодно и пашет все у абона. Твои рассуждения опытного человека который прилично походил по граблям и больше не хочет компромиссов. Но не всем доступна такая возможность. Могу открыть тебе страшную тайну, до сих пор есть сети которые сейчас уже под крылом (собственность

По моему кто то преувеличивает размер "проблемы". Сети бывают разные и не везде есть возможность, необходимость и главное целесообразность делать так как тобой описано выше. Клоны маков вполне сносно и быстро находятся, дается по жопе монтажникам или абонам которые натупили с клонированием. Авторизовывать абонента по маку без всяких там опций вполне рабочее решение, при грамотном подходе и дизайне сети. Что Вы еще готовы сделать или предпринять, чтоб не диагностировать причину а не тщетно бороться с ее последствиями?

Дякую. В цiкавому менi кєйсi OPT82 та DHCP Snooping не використовуєтся на OLT Stels.

С продажей домашнего инета от КС и не только есть один технический момент, нет света - нет инета. На старте Вам в районе 20Грн/Мбит выставят и это еще в зависимости от точки. Дате и остальным в целом пох на возможное получение от "вас копеек".