admin Опубликовано 1 декабря, 2012 Жалоба Share Опубликовано 1 декабря, 2012 При переходе с физ. на юр. лицо после заполнения всех данных у клиента все тот же тариф и в спецификации тоже тариф для физ. лиц указан. Может имеет смысл при переходе указывать желаемый тариф для юр. лиц и его в спецификацию включать? Вроде все правильно. Клиент до перехода оплатил именно тот тариф, который ему нужен. Однако правда тогда у юр. лица появляется возможность продлить услуги по тарифу, не предназначенному для юр. лиц. Полагаю, что надо лишь сделать запрет на продление услуг по тарифу, не предназначенному для типа аккаунта (физ/юр. лицо)? При расторжении Договора юр. лицом выдается только один документ. Вы тот, в котором указывается сумма к возврату не делали? Я 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 и т.д. Ссылка на комментарий Поделиться на другие сайты More sharing options...
partizansk.eu Опубликовано 2 декабря, 2012 Жалоба Share Опубликовано 2 декабря, 2012 Не хватает шаблонов договоров в /admin/template/LANG/: contract_hosting_ur.php contract_reselling_ur.php и т.д. Где можно скачать эти шаблоны? Скачал скрипт их там нет. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 2 декабря, 2012 Автор Жалоба Share Опубликовано 2 декабря, 2012 Смысл в том, что при переходе с физ. на юр. клиент должен выбрать нужный тариф из линейки для юр. лиц, чтобы он был в спецификации. Запрещать что-то я смысла не вижу. Предполагается, что после заключения Договора клиент получает счет и в нем выбранный тариф. Должно быть именно так, иначе сама суть спецификаций теряет всякий смысл. Для юр. на физ. я думаю не надо ничего тут автоматизировать, но надо дать клиенту выбрать его будущий тариф для физ. лиц. Так как и расторжение и заключение будут проверяться руками сотрудниками после получения документов - все что надо это информацию о будущем тарифе. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 2 декабря, 2012 Автор Жалоба Share Опубликовано 2 декабря, 2012 Не хватает шаблонов договоров в /admin/template/LANG/: contract_hosting_ur.php contract_reselling_ur.php и т.д. Где можно скачать эти шаблоны? Скачал скрипт их там нет. Вы создаете их сами. Как и что в readme.doc есть. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 2 декабря, 2012 Автор Жалоба Share Опубликовано 2 декабря, 2012 Хотел добавить, что e-mail клиента нужен и для Договора и для других доков. Что-то вроде TMPL_email только клиента. Ссылка на комментарий Поделиться на другие сайты More sharing options...
partizansk.eu Опубликовано 2 декабря, 2012 Жалоба Share Опубликовано 2 декабря, 2012 Никто своими шаблонами не поделиться за денюжку? Нет времени особо разбираться с этим. Ссылка на комментарий Поделиться на другие сайты More sharing options...
admin Опубликовано 2 декабря, 2012 Жалоба Share Опубликовано 2 декабря, 2012 Смысл в том, что при переходе с физ. на юр. клиент должен выбрать нужный тариф из линейки для юр. лиц, чтобы он был в спецификации. Запрещать что-то я смысла не вижу. Предполагается, что после заключения Договора клиент получает счет и в нем выбранный тариф. Должно быть именно так, иначе сама суть спецификаций теряет всякий смысл. Для юр. на физ. я думаю не надо ничего тут автоматизировать, но надо дать клиенту выбрать его будущий тариф для физ. лиц. Так как и расторжение и заключение будут проверяться руками сотрудниками после получения документов - все что надо это информацию о будущем тарифе. Ок, сделаю в одной из ближайших сборок. Хотел добавить, что e-mail клиента нужен и для Договора и для других доков. Что-то вроде TMPL_email только клиента. Добавил для новой сборки: TMPL_useremail – основной e-mail клиента Никто своими шаблонами не поделиться за денюжку? Нет времени особо разбираться с этим. Так это же шаблоны договоров (условий предоставления услуг и пр.) и вроде как у каждой хостинг-компании свои условия и особенности Ссылка на комментарий Поделиться на другие сайты More sharing options...
partizansk.eu Опубликовано 3 декабря, 2012 Жалоба Share Опубликовано 3 декабря, 2012 Никто своими шаблонами не поделиться за денюжку? Нет времени особо разбираться с этим. Так это же шаблоны договоров (условий предоставления услуг и пр.) и вроде как у каждой хостинг-компании свои условия и особенности Да, это все понятно. Просто нужны сами шаблоны, а в них сменим договорные обязательства (текст). Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 3 декабря, 2012 Автор Жалоба Share Опубликовано 3 декабря, 2012 Могу поделиться как только все сами запустим, бесплатно конечно, брать за это $$ не корректно мне кажется. Ссылка на комментарий Поделиться на другие сайты More sharing options...
partizansk.eu Опубликовано 3 декабря, 2012 Жалоба Share Опубликовано 3 декабря, 2012 Могу поделиться как только все сами запустим, бесплатно конечно, брать за это $$ не корректно мне кажется. Как только так сразу - пишите в личку. Спасибо. На кофе с печеньками все же скину. Ссылка на комментарий Поделиться на другие сайты More sharing options...
admin Опубликовано 3 декабря, 2012 Жалоба Share Опубликовано 3 декабря, 2012 Смысл в том, что при переходе с физ. на юр. клиент должен выбрать нужный тариф из линейки для юр. лиц, чтобы он был в спецификации. Запрещать что-то я смысла не вижу. Предполагается, что после заключения Договора клиент получает счет и в нем выбранный тариф. Должно быть именно так, иначе сама суть спецификаций теряет всякий смысл. Для юр. на физ. я думаю не надо ничего тут автоматизировать, но надо дать клиенту выбрать его будущий тариф для физ. лиц. Так как и расторжение и заключение будут проверяться руками сотрудниками после получения документов - все что надо это информацию о будущем тарифе. При изменении типа аккаунта появился выпадающий список с тарифными планами для нового типа аккаунта. После изменения типа аккаунта администратору в ожидаемые действия добавляется информация: ChangeAccountType and package: Старый тариф -> новый По юр. лицам вроде ничего больше не надо или что-то пропустил? Архив обновил. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 4 декабря, 2012 Автор Жалоба Share Опубликовано 4 декабря, 2012 Пока вроде все. Проверяю. Если что - отпишу. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 4 декабря, 2012 Автор Жалоба Share Опубликовано 4 декабря, 2012 При смене с физ. на юр. выпадающего списка тарифов нет, уведомления на главную нет. При смене с юр. на физ. вообще кнопка не активна. Также в расторжении, если один раз открыть документ больше не меняется дата от "". Если клиент случайно документ открыл посмотрел и не отправил? Ссылка на комментарий Поделиться на другие сайты More sharing options...
admin Опубликовано 4 декабря, 2012 Жалоба Share Опубликовано 4 декабря, 2012 При смене с физ. на юр. выпадающего списка тарифов нет, уведомления на главную нет. Проверил. Есть. Выпадающий список появляется, если текущий тарифный план предназначен только для физ.лица если аккаунт физ. лица и соответственно юр. лица, если аккаунт оформлен на юр. лицо. В списке отображаются тарифные планы, предназначенные для нового типа аккаунта или доступные для обоих типов аккаунтов. При смене с юр. на физ. вообще кнопка не активна. Видимо, не заполнена поле "компания". Также в расторжении, если один раз открыть документ больше не меняется дата от "". Если клиент случайно документ открыл посмотрел и не отправил? Какая именно дата? Все даты в примере ниже - это даты заключения договора: Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 7 декабря, 2012 Автор Жалоба Share Опубликовано 7 декабря, 2012 Так в расторжении нужна текущая дата расторжения. Если есть такой TMPL прошу его озвучить, добавлю сам. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 10 декабря, 2012 Автор Жалоба Share Опубликовано 10 декабря, 2012 Поправка по актам о выполненных работах. Такие акты должны быть доступны клиенту либо по окончании срока платежа (хостинг), либо сразу для одноразовых услуг (домен, сертификат и т.п.). Пусть акт будет виден сразу, но число в нем должно стоять окончания платежа. Также в шаблоне акта не работает TMPL_address клиента. Ссылка на комментарий Поделиться на другие сайты More sharing options...
admin Опубликовано 13 декабря, 2012 Жалоба Share Опубликовано 13 декабря, 2012 Так в расторжении нужна текущая дата расторжения. Если есть такой TMPL прошу его озвучить, добавлю сам. Добавил для договора: TMPL_current_dated – порядковый номер текущего дня TMPL_current_datem – название текущего месяца TMPL_current_datey – текущий год Поправка по актам о выполненных работах. Такие акты должны быть доступны клиенту либо по окончании срока платежа (хостинг), либо сразу для одноразовых услуг (домен, сертификат и т.п.). Пусть акт будет виден сразу, но число в нем должно стоять окончания платежа. Добавил для акта TMPL_datelast – дата окончания срока действия услуг по платежу Данные на основе конца "Периода оплаты" в информации по платежу. Если в этом поле ничего не указано, то берется дата платежа. Также в шаблоне акта не работает TMPL_address клиента. Исправил. Архив обновил. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 1. TMPL_datelast для домена показывает срок конца регистрации, так и было задумано? 2. Опять вернулась проблема с суммами и сдвигом таблицы платежей. Если юр. лицо оплачивает не безналом, то сумма верная, но так как нет акта, то таблица сдвигается влево. Если оплата безналом, то сумма опять видимо рассчитывается в $, а указывается в рублях. Причем сумма в таблице больше суммы в счете и акте. Прикладываю скрин. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 Для акта сверки надо два TMPL: Сумма всех безнальных платежей клиента за весь срок и сумма оказанных услуг, т.е. сумма безнала минус долг перед клиентом (сумма возврата). Ссылка на комментарий Поделиться на другие сайты More sharing options...
admin Опубликовано 15 декабря, 2012 Жалоба Share Опубликовано 15 декабря, 2012 1. TMPL_datelast для домена показывает срок конца регистрации, так и было задумано? Да, как я и писал выше, TMPL_datelast – дата окончания срока действия услуг по платежу 2. Опять вернулась проблема с суммами и сдвигом таблицы платежей. Если юр. лицо оплачивает не безналом, то сумма верная, но так как нет акта, то таблица сдвигается влево. Вроде как исправил. Проверьте после обновления скрипта. Если оплата безналом, то сумма опять видимо рассчитывается в $, а указывается в рублях. Причем сумма в таблице больше суммы в счете и акте. Прикладываю скрин. В админ-панели при редактировании записи о платеже какая сумма указана в: Сумма: RUR ? А вообще, для дальнейшего исследования проблемы необходимо следующее: 1. URL скрипта. 2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена; 3. Данные доступа на FTP с биллингом; 4. URL темы на форуме forum.advanta.org; 5. Номер платежа в админ-панели. На admin @ advanta.org Проверю опытным путем. Для акта сверки надо два TMPL: Сумма всех безнальных платежей клиента за весь срок и сумма оказанных услуг, т.е. сумма безнала минус долг перед клиентом (сумма возврата). Сделаю для одной из новых сборок (отпишусь на форуме в этой теме). Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 В платеже указано: Сумма: 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, прошу проверить. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 Для акта сверки нужно что-то похожее на спецификацию, чтобы в табличку вставлялись все оплаченные услуги, т.е. Регистрация домена 100р Размещение информации 300р .... Брать все платежи UR за весь срок действия аккаунта, складывать их, вычитать из полученной суммы остаток к возврату = получим сумму, на которую оказали услуги. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 И для того, что я указал выше нужен запрет платить чем то отличным от безнала для юр. лиц. Как мне объяснил бухгалтер - это самое правильное. В этом случае и остаток для возврата будет логично и правильно считаться. Тот чекбокс, что был ранее на активацию думаю можно изменить на любые платежи. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 15 декабря, 2012 Автор Жалоба Share Опубликовано 15 декабря, 2012 При переходе с физ. лица на юр. было бы неплохо зачислять остаток средств на карту оплаты. Потом клиент сможет оплатить с нее услуги, но в спецификацию они итак не попадут, так как это не безнальный платеж. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Vladimir812 Опубликовано 16 декабря, 2012 Автор Жалоба Share Опубликовано 16 декабря, 2012 Набросал пример акта сверки. Во вложении. Очень большой срочности в этом документе нет, срочнее то, что я выше писал. Ссылка на комментарий Поделиться на другие сайты More sharing options...
Рекомендуемые сообщения
Для публикации сообщений создайте учётную запись или авторизуйтесь
Вы должны быть пользователем, чтобы оставить комментарий
Создать учетную запись
Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!
Регистрация нового пользователяВойти
Уже есть аккаунт? Войти в систему.
Войти