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

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


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

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

 

Вроде все правильно. Клиент до перехода оплатил именно тот тариф, который ему нужен.

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

Полагаю, что надо лишь сделать запрет на продление услуг по тарифу, не предназначенному для типа аккаунта (физ/юр. лицо)?

 

При расторжении Договора юр. лицом выдается только один документ. Вы тот, в котором указывается сумма к возврату не делали? Я 2 дока отправлял.

 

В шаблон cancellation_hosting_ur или т.п. можно добавить любые данные.

Если что-то не так, - сообщите.

 

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

 

В принципе, можно сделать автоматическое изменение тарифа на выбранный (если конечно выбранный тариф дешевле или равен по стоимости текущему тарифу). Выбор тарифа будет предлагаться, если текущий тариф не будет соответствовать новому типу аккаунта (физ/юр. лицо). Если есть предложения или пр., - сообщайте. Буду думать, как лучше реализовать это.

 

Письмо, которое приходит клиенту юр. лицу после регистрации совершенно в неадекватном виде, все в строчку.

 

Исправил.

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

 

После оформления заказа юридическим лицом при переходе на ...order/index.php?mod=contract

появляется File for hosting ur does not exist! Билд последний. Как я понимаю чего-то не хватает... что делать?

 

Не хватает шаблонов договоров в /admin/template/LANG/:

contract_hosting_ur.php

contract_reselling_ur.php

и т.д.

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

  • Ответов 431
  • Создана
  • Последний ответ

Топ авторов темы

Топ авторов темы

Изображения в теме

Не хватает шаблонов договоров в /admin/template/LANG/:

contract_hosting_ur.php

contract_reselling_ur.php

и т.д.

Где можно скачать эти шаблоны? Скачал скрипт их там нет.

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

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

 

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

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

Не хватает шаблонов договоров в /admin/template/LANG/:

contract_hosting_ur.php

contract_reselling_ur.php

и т.д.

Где можно скачать эти шаблоны? Скачал скрипт их там нет.

Вы создаете их сами. Как и что в readme.doc есть.

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

Хотел добавить, что e-mail клиента нужен и для Договора и для других доков. Что-то вроде TMPL_email только клиента.

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

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

 

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

 

Ок, сделаю в одной из ближайших сборок.

 

Хотел добавить, что e-mail клиента нужен и для Договора и для других доков. Что-то вроде TMPL_email только клиента.

 

Добавил для новой сборки:

TMPL_useremail			 – основной e-mail клиента

 

Никто своими шаблонами не поделиться за денюжку? Нет времени особо разбираться с этим. smile.png

 

Так это же шаблоны договоров (условий предоставления услуг и пр.) и вроде как у каждой хостинг-компании свои условия и особенности :)

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

Никто своими шаблонами не поделиться за денюжку? Нет времени особо разбираться с этим. :)

 

Так это же шаблоны договоров (условий предоставления услуг и пр.) и вроде как у каждой хостинг-компании свои условия и особенности smile.png

Да, это все понятно. Просто нужны сами шаблоны, а в них сменим договорные обязательства (текст).

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

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

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

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

Как только так сразу - пишите в личку. Спасибо. На кофе с печеньками все же скину. ;)

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

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

 

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

 

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

После изменения типа аккаунта администратору в ожидаемые действия добавляется информация:

ChangeAccountType and package:
Старый тариф  -> новый

 

По юр. лицам вроде ничего больше не надо или что-то пропустил?

 

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

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

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

При смене с юр. на физ. вообще кнопка не активна.

Также в расторжении, если один раз открыть документ больше не меняется дата от "". Если клиент случайно документ открыл посмотрел и не отправил?

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

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

 

Проверил. Есть.

 

post-1-0-01532200-1354643932_thumb.jpg

 

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

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

 

При смене с юр. на физ. вообще кнопка не активна.

 

Видимо, не заполнена поле "компания".

 

Также в расторжении, если один раз открыть документ больше не меняется дата от "". Если клиент случайно документ открыл посмотрел и не отправил?

 

Какая именно дата?

Все даты в примере ниже - это даты заключения договора:

 

post-1-0-69572400-1354643915_thumb.jpg

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

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

 

Также в шаблоне акта не работает TMPL_address клиента.

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

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

 

Добавил для договора:

TMPL_current_dated – порядковый номер текущего дня

TMPL_current_datem – название текущего месяца

TMPL_current_datey – текущий год

 

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

 

Добавил для акта

TMPL_datelast – дата окончания срока действия услуг по платежу

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

 

Также в шаблоне акта не работает TMPL_address клиента.

 

Исправил.

 

 

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

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

1. TMPL_datelast для домена показывает срок конца регистрации, так и было задумано?

 

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

post-5655-0-20747200-1355571177_thumb.png

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

Для акта сверки надо два TMPL:

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

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

1. TMPL_datelast для домена показывает срок конца регистрации, так и было задумано?

 

Да, как я и писал выше,

TMPL_datelast – дата окончания срока действия услуг по платежу

 

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

 

Вроде как исправил. Проверьте после обновления скрипта.

 

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

 

В админ-панели при редактировании записи о платеже какая сумма указана в:

Сумма: RUR

?

 

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

1. URL скрипта.

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

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

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

5. Номер платежа в админ-панели.

На admin @ advanta.org

 

Проверю опытным путем.

 

Для акта сверки надо два TMPL:

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

 

Сделаю для одной из новых сборок (отпишусь на форуме в этой теме).

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

В платеже указано: Сумма: 200 RUR

А ниже, где блок связанный именно с юр. лицами указано иначе: Конечная сумма к оплате: 6 руб.

Данная ситуация происходит, если не получить в биллинге клиента счет и активировать услугу. Если получать счет, то проблем нет. Единственное - Notice: Use of undefined constant addtomail3 - assumed 'addtomail3' in /home/orderbh/public_html/index.php on line 15364 при первом просмотре счета, в последующих ошибки нет.

 

Таблица платежей отображается теперь правильно.

 

В договоре и остальных документах не работают переменные - TMPL_2director, TMPL_2position и TMPL_2 ustav, прошу проверить.

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

Для акта сверки нужно что-то похожее на спецификацию, чтобы в табличку вставлялись все оплаченные услуги, т.е.

Регистрация домена 100р

Размещение информации 300р

....

Брать все платежи UR за весь срок действия аккаунта, складывать их, вычитать из полученной суммы остаток к возврату = получим сумму, на которую оказали услуги.

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

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

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

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

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

Набросал пример акта сверки. Во вложении.

 

Очень большой срочности в этом документе нет, срочнее то, что я выше писал.

post-5655-0-42319000-1355648267_thumb.png

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

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

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

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

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

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

Войти

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

Войти

×
×
  • Создать...