Форум

[QUOTE]Василий Мазурок пишет:
Если в двух словах.
Запросом выбираем документы и получаем ТЗ с полями "идентификатор" и "Документ". Далее проходим циклом по ТЗ загруженных с сайта документов и ищем в ТЗ полученной запросом. Если находим берем документ и работаем - не находим - создаем новый документ. А для оптимизации можем добавить созданный документ в эту же таблицу - что бы избежать обращений к БД при поиске этого заказа в следующих итерациях цикла.....
Например при создании ПКО что бы не искать вновьсозданный документ в БАЗЕ - берем его из таблицы - предварительно его туда добавив.
[/QUOTE]Хорошо. Я в следующей версии модуля обмена сделаю, чтобы с запроса искались только те документы, ид которых в XML.

Т.е. в запросе вместо:
<Документ>.Б_Идентификатор <> """"
Будет:
<Документ>.Б_Идентификатор В (&СписокИдДокументов)

[QUOTE]Василий Мазурок пишет:
Теперь вот к логике - насколько логично каждый раз для проверки наличия в базе 1-го заказа - заставлять сервер выбирать заказы за несколько лет работы и осуществлять операции по записи нескольких сотен тысяч записей во временную таблицу.

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

Все вышесказанное сказано сугубо как личное мнение, и если я чего недосмотрел - прошу меня простить и просветить ....
[/QUOTE]Все идентификаторы документов хранятся в общем реквизите Б_Идентификатор. Т.е. чтобы получить все эти идентификаторы - придется перебирать все эти документы. А хранить их постоянно в течении сеанса где то - не очень хорошо это, да и не всегда полезно.

Я думаю, что прикручу к этому запросу условие по точке актуальности из настройки обмена. Она как раз нужна, чтобы отсеивать старые документы. А может и нет, т.к. он все равно эти документы прочитает.

[QUOTE]Иван Вялков пишет:
[QUOTE] Александр Денисюк пишет:
нет. Все 5 выгрузятся в одной настройке. Там устанавливается соглашение, которое подставится в заказ.
[/QUOTE]у меня можно выбрать только одно соглашение
[/QUOTE]там где вы смотрите - это соглашение подставляется в заказ. выгружаются все, которые удовлетворяют условиям выгрузки.
Тут условия выгрузки соглашений: http://1c.1c-bitrix.ru/support/forum/forum26/topic65679/#

[QUOTE]Василий Мазурок пишет:
[QUOTE] Александр Денисюк пишет:
В этом случае все заказы пакета документов будут всегда выгружаться, вне зависимости нормально они загружены, или нет. А это нагрузка на сервер 1С и сайта
[/QUOTE]Может идеальным вариантом был бы компромисс между первым и вторым вариантом. Когда косячные документы в 1С не загружаются, однако на сайт отдается информация о том что конкретные документы не загружены.?

Для этого необходимо несколько переделать логику ответа 1С на сайт. Но зато на сайте появилась бы возможность отметить когда и как загрузился в 1С тот или иной заказ. "Зеленая лампочка" - документ в 1С загружен. "Желтая лампочка" - документ ожидает загрузки. "Красная лапочка" - документ не загрузился в 1С из-за ошибки. Да еще и ошибку из 1С показывать.

И тогда и менеджер сайта будет в курсе что у него что-то не выгрузилось в 1С. И нагрузки на сайт не будет. Не будет происходить потери заказов из-за молчаливого поведения процедуры обмена.
[/QUOTE]Да, такой вариант был бы хорош.

Напишите идею тут: http://idea.1c-bitrix.ru/category/bitrix/1c_integration/
Может и включат в планы.

[QUOTE]Василий Мазурок пишет:
В ходе загрузки документов с сайта, в случае если обнаруживается какое-либо несоответствие (не указан номер или не заполнена дата или же не та хоз.операция) происходит пропуск документа и переход к следующему документу в списке. А по окончанию загрузки на сайт отправляется информация об успешной загрузке документов, что приводит к пометке документов как успешно-выгруженные и сайт не выгружает их в 1С пока заказ не будет изменен повторно.

Вопрос - разумно ли это считать загрузку успешной если в процессе загрузки происходили ошибки. Т.е. оператор магазина - отправил заказы в доставку, и думает что заказ попал в 1С. А в реальности заказ не попал никуда...и в 1С об этом нет ошибок (только в логе информация)
[/QUOTE]Если загрузка происходит так как сейчас, то:

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

Если загрузка происходит по другой схеме:
Появился косячный заказ из за которого положительный ответ на сайт не отправляется. В этом случае все заказы пакета документов будут всегда выгружаться, вне зависимости нормально они загружены, или нет. А это нагрузка на сервер 1С и сайта.

[QUOTE]Артур Моцкевичус пишет:
Здравствуйте! у меня вопрос/проблема.
есть 1с-ка УТ 11.1.6.20 Выгружаю товар, все выгружается- товар / св-ва. Но не выгружается не один тип цен. подскажите в чем может быть проблема? может в 1с что не так настраиваю.
[/QUOTE]
Наверн тут ответ.
http://1c.1c-bitrix.ru/support/forum/messages/forum26/topic65679/message344709/?result=reply#

[QUOTE]Виктор Третьяков пишет:
Выставил режим совместимости 8.2.16. При попытке объединить конфигурации вылезает ошибка:
ОпределяемыйТип.РаспоряжениеНаПоступление: Использование определяемых типов в режиме совместимости 8.3.2 и ниже недопустимо.
[/QUOTE]Этот режим нужно ставить для конфигураций на неуправляемых форм. Т.е. УТ 10.3, КА и УПП.

Если у вас конфигурация не на управляемых формах, но платформа 1С 8.3 - желательно не ставить режим совместимости "Не использовать". Лучше указывать "8.2.16". Некоторые релизы конфигураций плохо работают без режима совместимости.

[QUOTE]Иван Вялков пишет:
[QUOTE] Александр Денисюк пишет:
должно быть 5 соглашений, у каждого свой вид цены.
[/QUOTE]и для каждого соглашения свою настройку обмена??)
[/QUOTE]нет. Все 5 выгрузятся в одной настройке. Там устанавливается соглашение, которое подставится в заказ.

должно быть 5 соглашений, у каждого свой вид цены.