mixa писал(а):Круто!
Почти web-админка по платежам!
Еще каменты к платежам для пользователя и админа можно прикрутить аналогично методу платежа.
Прикол с авторизацией связанный с нововведением по ip
Кидает назад с аксесом денидом, хотя в прошлой версии все ок!
Да, и на странице по вводу платежей предупреждение ничего лишнего не нажимать, а вдруг кассир нажмет рефреш??
И.. повторный платеж!
Вот наш вариант админки, скажу сразу пока распостранять не планируем, но помочь обойти трудности с которыми мы столкнулись смогу...
Пояснения
0) Последний платеж показывает последний проведенный именно этим кассиром платеж, потому как постоянно отвлекаеют кассира а потом кассир вспоминает: провел он этот платеж уже или нет.
1) Поиск. При вводе логина или фамилии после первых 3 букв через AJAX ищутся и выводятся подсказка по первым 10 подходящим абонентам. Все подошедшие под результаты поиска учетки выводятся в списке, если в результате выборки одна учетка то она сразу переносится в форму, далее при клике данные абонента переносятся в форму, в поле комментария подставляется баланс на момент платежа и складывается с тем комментарием что вел кассир, в момент поиска также генерится случайное число которое потом учавствует в хеше платежа
1а) Кликнув на ID переходим на информацию о пользователе
1б) Кликнув на баланс появляется приведенное окно со всеми транзакциями пользователя, сделано затем что кассира постоянно спрашивают а когда я платил последний раз и прочую фигню.
2) Хеш платежа. Формируется по логину, сумме, дате, через кого и рандомного полученного числа, это обеспечивает уникальность на всех стадиях проведения платежа
3) все платежи заносятся в таблицу с уникальным столбцом хеша,
3а) Пока не заполнены нужные поля кнопка не активна
3б) После нажатия на кнопку идет внос в предварительную таблицу, далее идет очищение переменных и редирект на этуже страницу чтобы нельзя было отправить дубль по рефрешу, но даже если рефреш бы срабатывал то это бы ничего не дало так как данные в предварительную таблицу бы не вставились с одинаковым хешем.
4) Потом платежи из предварительной таблицы считывает скрипт по крону раз в минуту и заносит в биллинг. Почему не сразу в биллинг? Чтобы дать возможность проводить платежи когда база недоступна или биллинг нагружен какой либо фигней, так же это позволяет не ждать проведения платежа а сразу перреходить к другому
4а) Перед заносом в биллинг скрип проверяет отсутствие такого хеша после заноса проверяет наличие хеша. только потом ставится признак в предварительной таблице что платеж обработан.
4б) Скрипт при запуске проверяет наличие другой запущенной копии если есть дубль кончает себя.
5) Платежи в очереди на внос отображаются зеленым, если платеж в очереди стоит более 10 минут он становится красным и посылается уведомление админу. это значит что скрипт минимум раз 10 не смог внести его в базу.
6) Доступны отчеты которые берутся из базы реального биллинга
6а) Период отчета по умолчанию текущий день, ну и экспорт пока в эксель, но потом и в 1с будет.
