Дмитрий Васильев (Все сообщения пользователя)

Цитата
Андрей Ковач написал: надо иметь два инфоблока

По логике зачем иметь 2 инфоблока - в CRM должно по уму работать и редактироваться те же товары что и в магазине и 1 инфоблок на 2 сайта - но что получается - не умеет crm работать в товарах с торговыми приложениями и те же свойствами типа справочник если хранятся в HL блоках теже SKU - цвета.
Когда доработается этот момент чтобы в CRM менеджер работал с теми же товарами и мог там их редактировать если у них свойства - справочник и т д. как в самом сайте магазина. ну и конечно работа с торговыми предложениями.? по этой теме много нареканий.
Менеджер что ведет товары - не должен работать в магазине - пусть все товары по уму редактируются, добавляются и торговые предложения и все справочники в CRM товарах.
Ждем комментария от разработчиков.

Ну в последних редакция tree 17+ "глючит" по черному - например - если мы имеем раздел то явно когда он корневой у нас index файл главной страницы раздела, переходим в раздел и что - меню не развернуто. зачем этот шаблон с папкой иконкой в котором пользователь должен еще додумать а нажимать или нет на иконку когда в нормальных вариантах нет иконок а просто список - перешел в раздел если есть что в нем то открыты все пункты .. когда в нормальных все проще, и тут еще с кучей js ненужного когда все решается на просто css.
Может реально сделать нормальный человеческий шаблон скок лет то прошло а все нет, когда перешел пользователь на главную раздела то ему сразу раскрылся список подменю раздела - уже скок раз народ писал всем приходиться объяснять.

Документ «Закрытие заказов покупателей»

Цитата

Документ «Закрытие заказов покупателей» предназначен для снятия заказов покупателей с учета. Возможны следующие случаи необходимости оформления документа: Расторжение сделки – полная отмена оставшейся (не отработанной части) заказа. Закрытие заказа, когда считается, что он выполнен, даже если по данным учета он не сошелся «в ноль».  Остатки по заказу (товаров и оплаты) в этом случае просто списываются, как не требующие выполнения. Снятие резервов и размещения с заказов, например, в том случае если просрочен срок хранения резервов по заказам. В табличной части документа перечисляются закрываемые заказы и причины их закрытия. При заполнении заказа в документе в качестве справочной информации указывается информация о покупателе (контрагенте), которому был оформлен заказ, сумме заказа и об ответственном лице, оформившем заказ. В документе предусмотрено два вида операции. Снятие резервов и размещения. Позволяет снять существующие резервы и размещения по указанным заказам покупателей и поставщиков. Закрытие заказов от покупателей. Эта операция позволяет как снять резервы по заказам, так и аннулировать сами заказы. При этом заказы снимаются с учета, количество и сумма недоотгруженной номенклатуры по заказам погашаются в ноль. Заполнение документа может происходить тремя способами: ручным подбором в табличную часть документов, подлежащих закрытию; введением на основании документа «Заказ покупателя»; с помощью автоматизированного отбора документов по кнопке «Заполнить». Для операции «Снятие резервов и размещения» в автоотборе доступны следующие предустановленные виды заполнения: Все заказы с резервами. Отбираются все документы с наличием резервов и/или размещения. Неоплаченные в срок заказы (заполнение по просроченным резервам). Отбор только тех заказов с резервами и/или размещением, по которым нет полной оплаты покупателем, и истек срок хранения резерва без оплаты. Срок хранения резерва без оплаты задается в параметрах договора, по которому оформляется заказ. Для операции «Закрытие заказов от покупателей» виды заполнения следующие: Произвольный отбор. Позволяет пользователю самостоятельно определить все условия отбора, включая недоступные в других видах заполнения. Устаревшие заказы. Отбираются заказы, по которым давно не было никаких движений. А именно: нет резервов и размещения, не было оплаты, не было отгрузок, и истек «срок давности». Истечение срока определяется по «дате оплаты» и «дате отгрузки», установленным в заказах. Срок давности по умолчанию установлен [90 дней] и может быть изменен пользователем в пределах от 0 до 999 дней. Исполненные заказы. Исполненными считаются те заказы, по которым: нет задолженности покупателя по оплате, нет задолженности организации по отгрузке товара, отсутствуют (сняты) все резервы и размещения. Считается, что все работы по таким заказам успешно завершены и заказы подлежат закрытию. При этом на задолженность по отгрузке проверяется как сумма отгрузки по заказу, так и отгруженное количество номенклатуры по табличной части заказа. Отбор производится по следующим параметрам: наличие резервов; размещение резервов (на складах/в заказах); состояние отгрузки; дата отгрузки; состояние оплаты; дата оплаты. Кроме этого возможен отбор по реквизитам документа: контрагент, договор контрагента, вид операции, склад и т.д., а также по свойствам и категориям реквизитов. Документ проводится только в оперативном режиме. При проведении анализируются необходимые остатки на момент оформления документа. При проведении документа освобождаются резервы, выполненные по данному заказу. Если указанный в документе заказ покупателя размещен в каком-либо заказе, то это размещение также будет снято. В том случае, если выбран вид операции «Закрытие заказов от покупателей», то дополнительно к произведенным операциям будут списываться все существующие остатки по заказам покупателей и ожидаемым платежам. Для каждого заказа покупателя, в табличном поле можно указать причину закрытия. На основании данных о причинах закрытия заказов покупателей можно сформировать отчет «Анализ причин закрытия заказов».

По сути при закрытии заказа, когда ставишь выбранную причину должно влиять на отмену заказа, но что бы ты не ставил всё равно отмена.
Самое не маловажное это документ закрытия заказа Это не отмена заказа! Он может быть отменой конечно.

Из документации 1С - так может соответствовать ей, или если не может БУС так не делать, 95 % работают не по логике Битрикс а как удобней компании - если выпускается решение на рынок то в нем не должно быть навязывание логики работы клиенту а подстраиваться оно должно под любую логику какая клиенту удобна.

Коллеги как отменить при создании заказа на сайте что бы не создавались отгрузка и оплата, до обмена с 1С?

да очень хочется полной поддержки php 7 но еще нужно и решения в макете переводить если есть сторонние, а это либо сами или придется решать вопросы с авторами сами коллеги знаете что клиенты зачастую ставят себе решения и если мы перекинем на php 7 даже при том что сама платформа будет все поддерживать нам придется еще добиться поддержки у сторонних решений.
+ web окружение должно быть готово работать с php 7

Цитата
Александр Панишев написал: потребность в поддержке CentOS 7

ну + свои 2 копейки как снять лимиты на CentOS 7+ и Red Hat 7+ http://dev.1c-bitrix.ru/community/webdev/user/125153/blog/17437/

Попробуйте так удалить пакет

Код
erl-XML-SAX-0.96-7.el6

и пакет

Код
perl-XML-SAX-Base-1.04-1.el6.rf

и удалить

Код
/usr/share/man/man3/XML::SAX::Base.3pm.gz

и

Код
/usr/share/man/man3/XML::SAX::Exception.3pm.gz

 ну и сделать очистку  

Код
yum clean

- затем

Код
/bitrix-env.sh

 если не поможет тогда все выше перечисленное но перед установкой Битрикс установить пакет perl-XML-SAX-0.96-7.el6.noarch самостоятельно    
-точно 6.7 стоит.. потому как помню в 6.3 была вроде такая проблема. а репозитории

Код
yum repolist

точно стоят все стабильные от 6.7 ?  
 
Попробуйте так:

Код
# vi /etc/yum.repos.d/rpmforge.repo      exclude=perl-XML-SAX-Base # yum update

Цитата
yum remove имя пакета

там не просто Perl посмотрите имя пакета через  

Цитата
#yum list installed

возможно что обновилось в системе попробуйте установть с iso но не обновлять и проверьте зависимости  

Цитата
#yum deplist "имя пакета у которого смотрим"

, как вариант

Цитата
yum groupremove perl

. и все его пакеты
а точно ставите от сюда и так?

Цитата
wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh     chmod +x bitrix-env.sh ./bitrix-env.sh

Цитата
perl-XML-SAX-0.96-7.el6.noarch и пакет perl-XML-SAX-Base-1.04-1.el6.rf.noarch

 
 У вас уже установлен Perl вам и пишет что конфликт в версиях, удалите ту с которой увас идет конфликт через yum .

Цитата
# yum remove имя пакета

Вообще думаю что не на чистую щас установка идет раз уже Perl установлен. разберите что уже ставили чтобы в будущем не возникало конфликтов, и CentOS 6.7 minimal самое то для сервера.

Коллеги помогите решить проблему, чистая минимальная установка CentOS 6.7 + установлено окружение 5.1.5     + БУС и рабочий сайт. При добавлении сервера в pool CentOS 6.7 + установлено окружение 5.1.5 чистое ток задан пас bitrix такой же как и на главной машине, выдает ошибку в /opt/webdir/logs/ssh_keycopy.log:

Код
SSH_INIT - root connect to 192.168.1.2:22 SSH_CONNECT - SSH eof failure for 192.168.1.2:22

 
Вопрос снят    
Решение: нужно  поправить если у нас были сервера в пуле с таким же IP  что и мы пытаемся добавить в пул и возникает такая ошибка, то нужно удалить старые ключи по этим IP которые находятся в файле /root/,ssh/known_hosts - (рабочии ключи не удаляйте сделайте перед редактированием копию).    

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

есть 2 версии сайта на разных языках имена страниц одинаковые разница лиш в том что например:
1 URL /test/ 2 URL /en/test/
как лучше реализовать с сохранением в переменные при загрузки например страницы с /en/имя раздела/ - на выходе 2 переменные 1 понятна через $APPLICATION->GetCurPage() выведет /en/имя раздела/ во второй нужно вырезать и оставить только /имя раздела/