Перейти к содержанию
Форумы
Vladimir812

Работа с юр. лицами

Рекомендуемые сообщения

Мое видение данного вопроса:

 

1. Подарочный домен, первый год - подключение 0,01, в мес. ноль. На сл. год - подключение ноль, в мес. стоимость продления/12.

2. Обычный домен, первый и далее года - подключение ноль, в мес. стоимость продления/12.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ок, изменю для новой сборки отображение стоимости подключения как разницу между стоимостью регистрации и продления, если разница положительная.

Т.е. если регистрация и продление одна сумма, то ноль, если регистрация 200, а продление 100, то подключение 100 и 100/12 в мес? Что будет с этим доменом на сл. год? Опять стоимость подключения будет?

 

На данный момент - да. Вроде логично.

 

Мое видение данного вопроса:

 

1. Подарочный домен, первый год - подключение 0,01, в мес. ноль. На сл. год - подключение ноль, в мес. стоимость продления/12.

2. Обычный домен, первый и далее года - подключение ноль, в мес. стоимость продления/12.

 

Как высчитывать последующие года? Прошло 365 дней с момента активации домена или как-то еще?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Немного не понял, 365 дней со дня регистрации прошло и показывать как по варианту 2 выше, а в течение этого срока (до 365 с момента регистрации) - по варианту 1 выше?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Касательно доменов, спецификация должна изменяться в 2х случаях:

 

1. Подарочный домен был продлен, т.е. стал не подарочным (было подключение 0,01, в мес. 0, стало подключение ноль, в мес. стоимость продления/12)

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

 

Также спецификация должна изменяться при активации доп. услуг (не разовых), либо при их удалении.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И все таки не хватает темплейтов для договора, а именно:

 

1. Почтовый адрес исполнителя и заказчика

2. Факс исполнителя и заказчика

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Также вижу есть вариант смены аккаунта клиентом с юр. на физ. и наоборот. Где это можно отключить для клиента?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. При выставлении счета юр. лицу за домен:

 

Оплата по договору 41259/05-01-2012, размещение информации

 

Хотелось бы, чтобы в счете было продление домена. Касательно других услуг тоже, например, дополнительная услуга хотя бы указывать. не важно какая.

 

У физ. лиц как раз с этим все отлично: размещение информации НА какой домен, регистрация домена, продление регистрации. Кроме доп. услуг - также размещение информации, думаю надо поправить.

 

У юр. лиц в счетах и актах должно быть аналогично физ. лицам, только доп. услуги подправить.

 

2. Юр. лицо, аккаунт не активирован, на главной:

Notice

: Undefined index: contact in

/home/****/public_html/index.php

on line

2598

После заключения договора вместо этого текста появится ссылка на счет на оплату.

 

 

Не зависит от заключен договор или нет, Текст ошибки один.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Просмотрел все возможные варианта услуг/доменов/хостинга и подвел итог:

 

В спецификации логично сделать:

хостинг - размещение информации на "домен"

домен - обслуживание домена "домен"

доп. услуга - дополнительная услуга "услуга"

 

P.S. Если доп. услуга бесплатна, т.е. включена в тариф, то она также должна быть, подключение и ежемесячно ноль руб.

 

В актах и счетах:

хостинг - размещение информации на "домен" (указывать срок до или на сколько мес.)

домен - регистрация/продление домена "домен" (также сроки)

доп. услуга - дополнительная услуга "услуга" (срок)

 

Для физ. лиц при просмотре платежей 3 строки выше также актуальны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И все таки не хватает темплейтов для договора, а именно:

 

1. Почтовый адрес исполнителя и заказчика

2. Факс исполнителя и заказчика

 

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

Для физ. лиц будет не лишним ввести темплейт мобильного телефона для использования в Договоре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Касательно доменов, спецификация должна изменяться в 2х случаях:

 

1. Подарочный домен был продлен, т.е. стал не подарочным (было подключение 0,01, в мес. 0, стало подключение ноль, в мес. стоимость продления/12)

 

Сделал для новой сборки.

 

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

 

Тогда обновляются все спецификации, т.к. запись о домене из биллинга исчезает и соответственно при генерации спефицикации не используется.

 

Также спецификация должна изменяться при активации доп. услуг (не разовых), либо при их удалении.

 

Аналогично.

 

И все таки не хватает темплейтов для договора, а именно:

 

1. Почтовый адрес исполнителя и заказчика

Добавить почтовый адрес хостера в /admin/?mod=options&what=firma ?

Добавил для новой сборки переменную

TMPL_postaddress – почтовый адрес

 

2. Факс исполнителя и заказчика

 

Также добавить данные в настройку выше плюс в данные по клиенту добавить поле факса?

 

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

 

Фраза "совпадает с юридическим" не устраивает? Чем?

 

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

 

Используйте поле

Загружен к регистратору:

или изменяйте статус на "VISIBLE"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. При выставлении счета юр. лицу за домен:

 

Оплата по договору 41259/05-01-2012, размещение информации

 

Хотелось бы, чтобы в счете было продление домена. Касательно других услуг тоже, например, дополнительная услуга хотя бы указывать. не важно какая.

 

У физ. лиц как раз с этим все отлично: размещение информации НА какой домен, регистрация домена, продление регистрации. Кроме доп. услуг - также размещение информации, думаю надо поправить.

 

У юр. лиц в счетах и актах должно быть аналогично физ. лицам, только доп. услуги подправить.

 

Попробуйте согласно документации использовать переменную:

TMPL_item – название услуги, эту переменную можно указать вместо текста “размещение информации” в ur.php

Сообщите, если все равно не устраивает (Чем? во всех деталях).

 

2. Юр. лицо, аккаунт не активирован, на главной:

Notice

: Undefined index: contact in

/home/****/public_html/index.php

 

 

on line

2598

 

 

 

После заключения договора вместо этого текста появится ссылка на счет на оплату.

 

 

 

Не зависит от заключен договор или нет, Текст ошибки один.

 

Спасибо, исправил (во вчерашнем обновлении архива, после беглого просмотра темы на форуме).

 

Просмотрел все возможные варианта услуг/доменов/хостинга и подвел итог:

 

В спецификации логично сделать:

хостинг - размещение информации на "домен"

домен - обслуживание домена "домен"

доп. услуга - дополнительная услуга "услуга"

 

 

Текст длинный. Мешать не будет? Сделаю, если не будет :)

 

P.S. Если доп. услуга бесплатна, т.е. включена в тариф, то она также должна быть, подключение и ежемесячно ноль руб.

 

Как именно определять, что услуга бесплатна?

 

В актах и счетах:

хостинг - размещение информации на "домен" (указывать срок до или на сколько мес.)

домен - регистрация/продление домена "домен" (также сроки)

доп. услуга - дополнительная услуга "услуга" (срок)

 

Для физ. лиц при просмотре платежей 3 строки выше также актуальны.

 

Также см. переменную TMPL_item как указано выше.

 

И все таки не хватает темплейтов для договора, а именно:

 

1. Почтовый адрес исполнителя и заказчика

2. Факс исполнителя и заказчика

 

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

Для физ. лиц будет не лишним ввести темплейт мобильного телефона для использования в Договоре.

 

Добавил переменную

TMPL_mobilephone – номер мобильного телефона

 

Архив обновил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Да, добавить поля факса в настройки исполнителя и заказчика.

 

2. Фраза совпадает с юридическим устраивает. А если не совпадает? Нужен темплейт почтового адреса клиента в любом случае. Причем, если совпадает, чтобы по данному темплейту прописывался адрес.

 

3. Для спецификация длинный текст ничем не мешает, наоборот все прозрачно и понятно.

 

4. Определять, что услуга бесплатна, если стоимость ее ноль установлена. Ведь в этом случае даже клиенту пишется, что она бесплатна, значит уже определяется как то.

 

И если аккаунт не активирован, то в Договоре отсутствует первая спецификация, просто выводится MPL_specification. А она должна быть, так как клиент ее подписывает вместе с Договором.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Да, добавить поля факса в настройки исполнителя и заказчика.

 

Добавил.

Переменные:

TMPL_fax – номер факса

TMPL_our_fax – номер факса

 

2. Фраза совпадает с юридическим устраивает. А если не совпадает? Нужен темплейт почтового адреса клиента в любом случае. Причем, если совпадает, чтобы по данному темплейту прописывался адрес.

 

Добавил.

Переменные:

TMPL_postaddress – почтовый адрес

TMPL_our_postaddress – почтовый адрес

 

3. Для спецификация длинный текст ничем не мешает, наоборот все прозрачно и понятно.

 

Изменил.

 

4. Определять, что услуга бесплатна, если стоимость ее ноль установлена. Ведь в этом случае даже клиенту пишется, что она бесплатна, значит уже определяется как то.

 

Сделал.

 

И если аккаунт не активирован, то в Договоре отсутствует первая спецификация, просто выводится MPL_specification. А она должна быть, так как клиент ее подписывает вместе с Договором.

 

Проверил, на неактивированном аккаунте (с платежом UR_Bank в статусе WAITING) отображается единственная спецификация вида

post-1-0-10225600-1348686842_thumb.jpg

 

Архив обновил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Переменная TMPL_fax не работает, если прописать через аккаунт клиента, то не сохраняет в данные об организации. К тому же, не спрашивает вопрос-ответ при изменениях данных организации.

Если прописать факс в админке, то сохраняется, но темплейт не работает, просто отображает пустое поле.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если адрес почтовый совпадает с юр. адресом, то надо дублировать его, а не писать ,что совпадает.

 

Выше спрашивал - где можно отключить возможность смены физ. на юр. и наоборот для клиента?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отображение платежей, скрины я отправлял на почту. Исправили для физ. лиц, у юр. лиц все также - рубли равны USD, сдвиг таблицы, если платеж не оплачен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Переменная TMPL_fax не работает,

 

Исправил.

 

если прописать через аккаунт клиента, то не сохраняет в данные об организации.

 

Проверил, сохраняет.

 

Для дальнейшего исследования проблемы необходимо следующее:

1. URL скрипта.

2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена;

3. Данные доступа на FTP с биллингом;

4. URL темы на форуме forum.advanta.org;

5. UserID аккаунта и что и куда вводится в поле со стороны клиента.

6. URL страницы, на которой вводятся эти несохраняющиеся данные.

На admin @ advanta.org

 

К тому же, не спрашивает вопрос-ответ при изменениях данных организации.

 

Так и должно быть, изменение данных по организации секретным вопросом не закрывается.

Если хакер и додумается изменить эти данные, то по их изменению и можно будет судить о том, что в аккаунт влез кто-то посторонний. Малой бедой клиент отделается в этом случае :)

 

Если адрес почтовый совпадает с юр. адресом, то надо дублировать его, а не писать ,что совпадает.

 

Чем не устраивает информация о том, что совпадает? Лаконичнее ведь и не нужно сверять адреса.

 

Выше спрашивал - где можно отключить возможность смены физ. на юр. и наоборот для клиента?

 

Для какой цели необходима данная функция? Необходимости ее наличия не вижу. Допустим клиент передал дела на юр. лицо или наоборот, - значит данные клиенту нужно изменить.

 

Отображение платежей, скрины я отправлял на почту. Исправили для физ. лиц, у юр. лиц все также - рубли равны USD, сдвиг таблицы, если платеж не оплачен.

 

Для дальнейшего исследования проблемы необходимо следующее:

1. URL скрипта.

2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена;

3. Данные доступа на FTP с биллингом;

4. URL темы на форуме forum.advanta.org;

5. UserID аккаунта, у которого данные отображаются неверно.

На admin @ advanta.org

 

 

Архив, в т.ч. и для php 5.2, - обновил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Факс работает, спасибо.

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

3. Вопрос-ответ при изменении этих данных не нужен, согласен.

4. Если это сложно, то пусть будет как есть - совпадает с юридическим. Это не страшно.

5. Функция отключения возможности перехода на физ. лицо нужна, так как:

- не у всех клиенты физ. и юр. на одних серверах

- при переходе на физ. лицо могут быть использованы отдельные тарифы

- необходимо расторжение договора

 

Отсюда выводы:

- разрешать переключения самому клиенту нельзя

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

 

Саму форму соглашения можете и не делать - сделаем сами (при желании можно будет использовать шаблон в скрипте по дефолту), но для нее очень нужна переменная "остаток средств" и возможность изменения страницы возврата в аккаунте юр. лица (через lang или как угодно).

 

6. Данные для проверки отображения таблицы не оплаченных платежей (и валют) отправлю в течение часа.

 

В дополнение:

 

- Аккаунт не активирован, НО договор заключен - ссылки на счет на Главной нет, но и нет надписи, что требуется заключение договора

- Аккаунт не активирован, договор НЕ заключен - в списке платежей можно нажам на ссылку получить безнальный счет, а не надо бы.

 

Что касается TMPL_item - полезный темплейт, но не для всего. Для доп. услуг и для пополнения карт не подходит совершенно (для карт просто пишет card).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, и сразу после заказа юр. лицо на почту получает счет, а должен получить сразу после статуса "заключен договор".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Исправил.

 

5. Функция отключения возможности перехода на физ. лицо нужна, так как:

- не у всех клиенты физ. и юр. на одних серверах

- при переходе на физ. лицо могут быть использованы отдельные тарифы

- необходимо расторжение договора

 

Отсюда выводы:

- разрешать переключения самому клиенту нельзя

 

Добавил.

 

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

 

Поясните, пожалуйста, как именно нужно было бы изменить форму moneyback для физических лиц (в деталях, что на что поменять и пр.)

 

Саму форму соглашения можете и не делать - сделаем сами (при желании можно будет использовать шаблон в скрипте по дефолту), но для нее очень нужна переменная "остаток средств" и возможность изменения страницы возврата в аккаунте юр. лица (через lang или как угодно).

 

Добавил в договор переменные

TMPL_moneyback_first		– сумма moneyback в первичной валюте
TMPL_moneyback_second	– сумма moneyback во вторичной валюте

 

 

6. Данные для проверки отображения таблицы не оплаченных платежей (и валют) отправлю в течение часа.

 

Вроде как исправил. Сообщите, если ошибка все равно продолжит иметь место быть.

 

В дополнение:

 

- Аккаунт не активирован, НО договор заключен - ссылки на счет на Главной нет, но и нет надписи, что требуется заключение договора

- Аккаунт не активирован, договор НЕ заключен - в списке платежей можно нажам на ссылку получить безнальный счет, а не надо бы.

 

Исправил

 

Что касается TMPL_item - полезный темплейт, но не для всего. Для доп. услуг и для пополнения карт не подходит совершенно (для карт просто пишет card).

 

Как именно не подходят для. доп. услуг?

Текст "card" исправил.

 

Да, и сразу после заказа юр. лицо на почту получает счет, а должен получить сразу после статуса "заключен договор".

 

Клиенту отсылалось верно, а вот администратору отсылался счет. Исправил письмо для администратора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если платеж за доп. услугу, то платеж отображается как Размещение информации, нельзя просто Доп. услуга написать?

 

По странице возврата я писал исключительно для юр.лиц. Там не должно быть никаких полей с реквизитами и переносами на другой аккаунт, так как возврат делается на тот же счет, с которого клиент оплачивал услуги. Там должна быть ссылка на 3 документа: Расторжения договора и акт сверки (пусть это будет один файл, состоящий из 2х страниц). Теперь, когда есть все необходимые переменные (остаток для возврата), мы можем сами сделать необходимые формы. От Вас нужно лишь внести в лэнг текст для страницы возврата и сообщить имя .php файла для расторжения и акта.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Протестил то, что исправили:

 

1. При попытке открыть платежи юр. лица из под юзера - 1054Unknown column 'status' in 'where clause'

 

2. Возврат средств у физ. лица. Если выбран способ на реквизиты, то секретный вопрос уехал вправо, видимо форматирование для него по правому краю стоит, а не по левому.

 

3. При заказе юр. лица, хотя и выбирается активный тариф, все равно подставляется тариф для физ. лиц, причем тот что выбран первым для отображения.

 

4. Юр. лицо не работает на основании договора оферты, а значит в заказе нет смысла заставлять ставить галку о его прочтении и вообще сомнительно нужен ли данный текст для юр. лица.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как называется почтовый темплейт, который используется для оповещении юр. лица после совершения заказа? В нем нет подписи, ссылка ведет не понятно куда (index.php?mod=contract).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

×