В УТ11 цены рассчитываются динамически в зависимости от соглашений, в базе порядка 100к товаров и 10к клиентов.
1. Можно сформировать прайс листы для всех клиентов и выгузить их на сайт, но тогда на сайте будет таблица из миллиарда записей.

2. Можно выгружать на сайт общий прайс, а цену формировать в зависимости от условий в соглашении уже на сайте, но тут очень сложный механизм расчета уже в самой 1С, прописать этот механизм на сайте крайне тяжело.

Как поступить?

1. Хранить цены клиента на сайте

2. Рассчитывать динамически

3. допилить 1С, чтобы сайт через вебсервисы обращался в 1С за ценами

"но тогда на сайте будет таблица из миллиарда записей" // Ну что же делать, коли у вас 10к клиентов и у каждого своя цена на товар. Дергать базу 1С каждый раз когда клиент смотрит товар (чтобы получать цены) кажется неправильным.

(0) А сайтом как пользуются? Как  каталогом с корзиной или просто цены посмотреть?

(2) Ну зачем каждый раз, можно один раз перед началом сеанса дернуть все цены клиента и дальше их использовать

(4) Тоже жесть какая-то. Клиент, наверное, и 1% от общего ассортимента не просмотрит на сайте.
Вообще по-правильному 1С должна выгружать цены на сайт как только в ней эти цены были изменены. Только этот вариант максимально гарантирует актуальность (правдивость) цен на сайте. У остальных вариантов либо высокая нагузка на базу 1С, либо степень гарантии актуальности (правдивости) цен на сайте меньше.

тут все сильно зависит от условий в 1С и возможностей сайта:
в идеале на сайт должен грузиться общий прайс, от которого уже под каждого клиента (группу клиентов) должна быть скидка/наценка к прайсу для соотв.номенклатуры (группы номенклатур)

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

мне видится так: разочек выгрузить все , а потом выгружать только измененные цены

(8) +1

если 1с не падает от <<миллиарда записей.
то и сайт не упадет, главное не гонять всё это постоянно туда-сюда

(8) Думаешь от этого таблица станет меньше? К тому же ТС спрашивает о хранении цен, а не о доставке

(10) В 1С нет миллиарда записей
В 1С есть прайс и в соглашении указано что для это группы для этого клиента +5, для этой группы +7, остальное по прайсу

На сайте такого нет, вот и вопрос, делать миллион записей, пилить сайт или свой вариант

Причем большинству клиентов вообще может тупо стоит к примеру +3 от прайса, или -1,5 от прайса на всё (например региональное деление)

(8) У клиента было скидка 2% от прайса стало 4%. В твоем случае это означает что нужно выгрузить таблицу с 100к записей (полный прайс для этого клиента)

Если пришло 500 новый позиций или переоценили 500 старый, это означает что нужно выгрузить 500*10к = таблицу с 5 000к записей.

Сильно поможет выгрузка изменения цены?


При втором варианте (реализовать ценообразование на сайте) нужно выгрузить в первом примере 1 строчку (клиент, новая скидка) и во втором примере таблица будет содержать 500 позиций (новые базовые цены)

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

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

(16) у пересчета из 1С есть такие минусы:
- если пересчитывать цены до фиксации заказа, то нужно дергать базу 1С, что не есть гут
- если пересчитывать цены после фиксации заказа: клиент может успеть оплатить заказ онлайн до пересчета

так что тут:
- либо договориться с клиентом о скидке от прайса;
- либо (если клиенту нужна фиксированная цена, независимо от изменений прайса) 2 вариант:
-- выгружать отдельный прайс с фикс.ценами для клиента;
-- пересчитывать скидки от нового прайса;

Спасибо всем за ответы, сайт - это B2B система, сейчас склоняюсь к варианту выгрузки цен для клиента на сайт при авторизации на сайте (дергаем веб сервис). Очищать таблицу цен при закрытии сессии на сайте.

Жесть...
Если на сайте использовать теже правила округления при расчёте, что и в 1С, то процентов 90-95 ошибок с конечными суммами можно избежать.
В случае, когда обнаружилось, что от клиента получена сумма отличающаяся от суммы заказа в 1С, поднять лог и прикинуть, что делать с этой копейкой, либо скидку дополнительную, либо наценку.
В случае, когда клиент заказал 1000 строк товаров, в каждой строке получим расхождение на 1 копейку (вроде как в пределах логики), в сумме получим расхождение на 10 рублей. Необходимо вспомнить, что минимальная денежная единица в России - 1 копейка и правила округления в математики работают одинаково для всех систем. И найти косяк в расчётах.

(0) нормализация данных. Т.е в выгружаем 2 таблицы - Цена(ключ, цена) и Контрагенты(Ключ,контрагент).

Самое сложное сделать таблицу с ключами

(0) Использовать ajax и http-сервисы для отображения цены на сайте. Проверяли - работает все это нормально. Запрос цены с сайта в 1С будет делать за за 0,3-0,5 секунды - вполне примлемо, замедления работы сайта не будет (потому что ajax).
Чтобы не нагружать основную базу запросами с сайта, можно сделать вторую урезанную базу, в которой будет храниться только список контрагентов и цен, синхронизировать ее с основной (частота синхронизации выполнения зависит от частоты смены цен). Тогда на работе основной базы это вообще никак не отразится, даже легче ей будет, чем если каждый раз как в (18) при логине клиента делать запрос на все цены и кидать их на сайт. При наличии денег у руководства можно вообще LocalStorage заюзать. При логине посетителя проверять, изменились ли для него цены, если нет - берем их прямо из LocalStorage браузера посетителя. Если цены в LocalStorage еще нет или цены обновились, то тянем из 1С, из второй базы.

(21) А теперь посмотри (16), конкретно второе предложение

(22) >> "а при оформлении заказа (документа) клиентом на сайте вызывать пересчет силами 1С и возвращать на сайт результат расчета (все цены и скидки)"
Почему при оформлении заказа? Цены должны быть видны еще до оформления заказа - судя по ТТХ в (0) там просто индивидуальные скидки от базовых цен, они не меняются в зависимости от количества товаров в заказе или его общей суммы.
Твой вариант подходит в случае, если скидки зависят от общей суммы заказа, количества заказанных товаров. Тогда отображаем на сайте некие базовые цены (их можно не тянуть из 1С), после набора заказа или его части жмем кнопку "Пересчет скидок" и видим промежуточный результат: окончательные цены, размер скидок, а заодно и наличие товара на складах. Такое тоже делали - еще проще в реализации.

Тут единственный вопрос, который может отнять здОрово времени, это CMS, на которой поднят сайт, а именно, как сделать так, чтобы загруженные из 1С цены подставлялись не только на страницу товара, но и в корзину, чтобы общая стоимость заказа на сайте считалась по ценам из 1С. Не во всех ЦМСках это получится сделать легко и без костылей.
А так - вообще никаких трудностей в реализации.

(23) Вот! Ты меня абсолютно правильно понял. Я доволен, вопросов больше не имею )

(25) Какие мы молодцы )