Форум

[QUOTE]Артем Северин пишет:
А это я не вам, извиняюсь-) Тихо сам с собой, я веду беседу  8)  

То есть у вас на сайте есть и простые товары, а есть и с ТП. А у простых товаров цены хранятся не в торговых предложениях, а обычно?

Если так, то мне пришлось изменить весь каталог и хранить цены в торговых предложениях.
[/QUOTE]На мой взгляд - это легко решается на стороне принимающей заказ (обычно это 1С)...
Правда, "легко" - это относительное понятие, мне вот было легко. Но без перепрограммирования типовых механизмов не обойтись.

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

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

[QUOTE]Александр Денисюк пишет:
думаю, что прикручу к этому запросу условие по точке актуальности из настройки обмена
[/QUOTE]А дата эта... она ведь тоже условна...
Установив его сегодняшним днем - мы будем выбирать только один день...
А через год (если не менять дату в настройках обмена - а ведь так оно и есть, работает никто и не трогает) - будем уже выбирать объемы годовой работы сайта.

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

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

И результат запроса или будет содержать документ с таким идентификатором или же не будет - если не будет - значит документ новый. Тогда и создаем новый заказ. Если же содержит - значит обновляем документ.

Если в двух словах.
Запросом выбираем документы и получаем ТЗ с полями "идентификатор" и "Документ". Далее проходим циклом по ТЗ загруженных с сайта документов и ищем в ТЗ полученной запросом. Если находим берем документ и работаем - не находим - создаем новый документ. А для оптимизации можем добавить созданный документ в эту же таблицу - что бы избежать обращений к БД при поиске этого заказа в следующих итерациях цикла.....
Например при создании ПКО что бы не искать вновьсозданный документ в БАЗЕ - берем его из таблицы - предварительно его туда добавив.

Прошу извинить за сумбурность... но более детально - проще уже код написать.

В исходном коде модуля Б_ПроцедурыОбменаССайтом есть процедура "СоздатьОбновитьДокументы".
В которой есть текст запроса, общая суть которого выбрать все документы из базы у которых заполнено поле Б_Идентификатор и записать их во временную таблицу

Это конечно не мое дело, указывать Вам как писать программы... но... с точки зрения логики - насколько разумно выбирать ВСЕ данные за ВСЕ периоды, сохраненные в базе, ради того, что бы проверить существование одного, двух, ну максимум десяти документов

Если я правильно понимаю идеологию (все выводы делаю на основании взаимодействия с собственным сайтом):
- частота обращений к сайту для запроса новых заказов у большинства довольно высокая (у меня например 5 минут);
- реал-тайм режим подразумевает что заказы будут "падать" в 1С сразу после появления их на сайте, а это значит 1 документ в пактее;
- даже без использования реал-тайм режима, при частых опросах сайта - количество заказов в одном пакете будет небольшим,около 10-15 (в среднем), зачастую это будет 1-2 заказа;

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

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

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

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

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

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

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

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

[QUOTE]Александр Денисюк пишет:
Сейчас только так. 1С получает только тогда номер на сайте, когда приходит заказ с сайта.
[/QUOTE]Ладно. А можно хотя бы сделать что бы заказ получив номер (после загрузки) - в БУСе отмечался как "измен" и сразу же выгружался в 1С?
А со стороны 1С после отправки заказов - выполнять еще один цикл запроса заказов.
И таким образом получить номера заказов "почти за один прход".

При выгрузке нового заказа из 1С на сайт - на сайте ему присваивается номер. Однако, сам по себе этот заказ в 1С назад не выгружается. Только после изменения его на сайте - произойдет выгрузка.
Как образом можно получить номер выгруженного на сайт заказа. Не могу же я заставлять своих операторов каждый раз изменять заказы и добавлять "." в комментарий что 1С получила номера выгруженных заказов.

Смотрю исходный код обмена заказами.
В процедуре "ЗагрузитьДокументыССайта" есть такая вот конструкция:
[CODE]
[/CODE][CODE] лЕстьДокументы = Истина;
     Пока лЕстьДокументы Цикл[/CODE]
[CODE] // вырезал кусок посвященный получению данных
           лЕстьДокументы = ЗагрузитьДокументы(СтрокаCML, ПараметрыОбмена);
     КонецЦикла;
[/CODE]

получается если с сайта получен хотя бы один документ - то будет посыл еще одного запроса на получение документов.
Объясните какова логика в этом?  Предполагается что за первым запросом сайт отдал не все? Или пока шел разбор данных - появились новые заказы и надо их снова разбирать?
Или может это просто ошибка