Всем привет!
У нас идет разработка интернет магазина. Встал вопрос: Как и где рассчитывать скидки-наценки?

Есть несколько идей: 1. Продублировать логику расчета из 1С(на мой взгляд не кошерно)
2. Через веб-сервис запрашивать скидки(это дополнительное время на обмен между сайтом и 1с)

Кто сталкивался с данной проблемой, как решали?

(0) я делала b2b систему и там было когда заказа попадал в 1с он пересчитывался по довольно сложным "скидочно-наценочным" правилам и по OBDC напрямую mySql "переписывался". Минус подхода что клиент сразу не видит свои конечные цены а только после оформления заказа (

Перенесите логику на отдельный веб-сервис и юзайте его и с сайта и из 1С...

(0) делали веб сервисами онлайн создание заказа в 1с

не такая уж там и задержка получается

(0) "Через веб-сервис запрашивать скидки(это дополнительное время на обмен между сайтом и 1с) " - правильно через http-сервисы делать. Времени на обмен с 1С много не требуется - у нас на рабочем примере страница открывалась в пределах секунды. Документ "ЗаказКлиента" в УНФ создается за полторы секунды.

(4)(2) Через веб-сервисы обмен через XML?

Сейчас спор идет о том, что бы рассчитывать скидки при добавлении товара в корзину..., т.е. постоянный пересчет...
Думаем как сделать это наиболее оптимально

(7) В варианте обсчитывать цены "на лету" - самый быстрый вариант (с точки зрения производительности) - продублировать всю логику на ВЕБ-сервере.
Компромисный вариант - иметь на ВЕБ-сервере "базовые цены", а цены "по конкретным торговым условиям" пересчитывать на стороне 1С при окончательном оформлении заказа, ну или по запросу. Когда покупатель понимает о чем речь и согласен на задержку в обработке.

(8) Это понятно, условно-постоянную инфу за день можно грузить раз в день. Динамически данные нужны максимально быстро. В общем еще никто четко не понимает стратегию как это будет, т.е. как клиент будет заказывать и на каком этапе ему будет рассчитаны скидки.

Поэтому и пытаюсь для себя выстроить данную схему..

(8) Вот только минус, что нужно постоянно синхронизировать логику работы, например у клиента поменялись условия

Еще можно хранить для каждого клиента свои цены :)

(11) А если цены зависят от количества и состава товаров в заказе? Хранить 100500мерный массив цен?

(10) Синхронизировать нужно в любом варианте. Пока сайт не узнает об изменениях не сможет вести обсчет по новым ксловиям.

(9) Код на "языке 1С" с ТЗ можно даже на linux уже выполнять, получать текст этого кода можно веб сервисом ))

(14)+ без 1С выполнять

(14) А смысл? Понта ради? PHP вы считаете не сможет потянуть арифметику?

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

(6) да.
Корзина - непроведенный заказ, при докидывании товаров - товары добавляются в таб часть и записываются. при оформлении - проводится и ставит товар в резерв (или нет, если всё уже расхватали :))

(16) Сколько времени займет повтор алгоритмов общих скидок и индивидуальных соглашений из 1С и на сайте? Куча ошибок будет.

(6) "Через веб-сервисы обмен через XML?" - правильно через http-сервисы через JSON.

(19) Ну нам выставили ценник с двумя нулями за повторения алгоритма ценообразования в Битриксе как в УТ11

(20) абсолютно пофиг

(22) Нет

т.е. оптимально сразу создавать заказ клиента в 1С при добавлении товара в корзину?

(23) да

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

+(26) Ну или если алгоритм расчета скидок работает в 1С, а не на сайте, то тоже дергать 1С каждый раз при изменении корзины.

(22) http://v8.1c.ru/o7/201312http/index.htm
>>Потенциально меньший объем передаваемых данных;
>>Потенциально меньшая вычислительная нагрузка;
А JSON более компактный по сравнению с XML.

(28) я тебе сейчас открою страшную тайну. 1с вполне вывозит десятки и сотни параллельных запросов без крохоборства. А в свою очередь SOAP гарантирует соответствие некоторой структуре, как запроса, так и ответа, что сильно упрощает работу, когда на одной из сторон происходит доработка.

(29) Так в ссылке из (28) уточнено, что эффект скорее будет заметен на мобильных устройствах. Но если уж делать с нуля, то почему бы не сделать сразу нормально.
А структура SOAP... Ну так на стороне 1С параметры http-запроса это соответствие, с ним очень удобно работать. Как раз таки при изменении на одной стороне ничего не упадет на другой.

(24) От количества одновременных заказов зависеть еще будет.

Нужно чтобы пользователям сайта-магазина тормозов не было, даже php вполне до 500 одновременно наполняющих корзину может потянуть.
В отличие от 1С ))

(30) каким, нафиг мобильным устройствам, если это веб сервер общается с сервером 1с? клиентов способ общения серверов вообще не волнует

(31) если модуль сеанса не конский, то и 1с в пределах разумного будет работать. А когда станет стабильным https://wonderland.v8.1c.ru/blog/povyshenie-proizvoditelnosti-veb-servisov/ так там вообще лафа

(32) Да, тут я тупанул, согласен.

(33) Я в разрабов типовых верю... что они любые возможности платформы сумеют запороть ))

внезапно вышла 8.3.9, так что можно потестить (33)