Нужно выгружать данные(справочники и отдельно остатки, цены) на сайт. Выгрузка полностью своя, ну там формирование xml файла и т.д., ну т.е. не через правила обмена, односторонняя выгрузка.
Собственно, что бы накапливать изменённые данные есть объект как "Планы Обмена". Ну, а может быть лучше использовать регистр сведений? Как то более прозрачнее что ли и места по идее должен меньше занимать.
Посмотрел замером производительности, в регистр будет писаться быстрее. Чтение, если запросом - то одинаково.
Проблема с удалением данных из регистра.
Допустим начинаем выгружать, считали данные, выгрузили, очистили регистр. Но пока выгружали - произошли новые записи туда, плюс возможно изменилиь данные в уже существующих объектах. В итоге просто так взять и очистить регистр нельзя, даже если будем очищать с отбором по единственному измерению, то это тоже нельзя + время.

Короче может кто сталкивался с таким замутом? Стоит оно того?
Хочется как лучше, а через ПланОбмена и само пойдёт)

У акселотовцев спроси. Они как-то говорили что регистр в своей конфе использовали из за каких-то проблем.

Изобретение велокатов с квадратными колесами - древняя традиция программистов вообще и одинэснегов в частности

Как один из вариантов реализации: тебе нужна ал-я версия записи в регистре. Для этого подходит например GUID.
Изменили объект - в регистре сделали запись с автоматически сфорированным ID.
Выгрузили объекты в XML вместе с их ID. На принимающей стороне прочитали и по тем объектам по которым все прошло удачно отправили обратно список подтвержденных ID.
На отправляющей стороне чистим записи с подтвержденными GUID-ами.
Если за время обмена объект изменился еще раз то он уже будет в регистре с другим ID.

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

(2) я в вас не сомневался. Даже глубокой ночью вы свои 5 копеек в такую тему из под подушки то достанете.

(3) А не этим ли занимается стандартный механизм обмена?

(5) Стандартный механизм не позволяет принять данные частями. Тоесть если не можешь принять хотя бы 1 объект то заворачивается весь пакет. В большинстве случаев это не нужно поскольку ошибку по непринятому объекту просто пишут в лог и он улетает из обмена, однако когда известно что объекты могут загружаться не с первого раза то нужно пообъектное подтверждение о доставке, чего схема с номеом принятого/номер отправленного сообщения обеспечить не может.

Можешь прописать ДатаЗаписи и Читать данные с последней даты, а удалять можешь в фоне порциями для уменьшения конфликта при ответе последней полученной даты.

А что бы не было проблем что при выгрузке на 1 секунду могут добавится еще объекты выгружать данные на секунду меньше последнего документа.

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

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

(2) или осознаная необходимость. Когда делал свою систему, тоже пришлось использовать РС т.к надо было записывать лог обмена.

(10) это да, слона то я и не заметил

(9) Да и замеры твои - фуфло. Потому, что 1с не предрставляет средств для замера записи в таблицы регистрации.

"Замер производительности" и ЗарегистрироватьИзменения() фуфло?

(11) Какая религия запрещает вести лог при использовании ПО?

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

(15) Не мешайте велосипедостроению.
А если серьёзно
(0) На хрена

"Не мешайте велосипедостроению"
Это единственная стабильно развивающаяся отрасль в России