Безопасность. На сайте придется хранить реальных покупателей с их паролями, скидками, историями заказов и т.д. Если фирма - представительство и покупатели - региональные оптовики, то вероятность контроля всех и вся (кто зашел, когда, с какого IP, с какими правами), особенно с учетом полного отсутствия встроенной системы многофакторной идентификации, очень мала. Да и Преста не для этого предназначена.
Надежность. Если на сайте-магазине реальный остаток, это может вызвать проблемы: конкурент подгадит, заказав весь товар, клиент увидит надпись "товара недостаточно, свяжитесь с менеджером" и просто уйдет и т.д. Живой человек всегда найдет решение: предложит схожий товар, дав скидку, нивелирующую разницу в стоимости, снимет с резерва другого покупателя и т.д. Машину обучить всем этим хитростям еще не скоро получится.
Риск. Существуют готовые решения онлайн торговли от 1С. Да, медленные, да, дорогие. Но поддерживаемые. Когда решения основаны на жесткой связке структур баз данных магазина и 1С, при следующем обновлении одного компонента может отвалиться все.
Поэтому, как и всегда, надо пользоваться принципом "делай проще, дурак". Предлагаемое решение не создает жесткой связки, а использует технологию создания запросов, которые необходимо выполнить в БД PrestaSop'а. Для удобства большинства пользователей, формирование выражено в виде электронной таблицы, где и формируются SQL-команды. Все что необходимо знать - это артикул товара в PrestaSop (надеюсь, у Вас он совпадает с 1С-совским, или, хотя-бы существуют таблица соответствий / "лишнее" поле в справочнике "Номенклатура") и цену, которую Вы собираетесь внести. Как видите, знания структуры баз данных или механизмов их работы не требуется вовсе.
Способ формирования электронной таблицы - стандартный прайс-лист 1С, фирменный отчет или еще какой-то специфический документ, рассылаемый клиентам - не совсем моя парафия. Из него нужен только код артикула, используемый в PrestaShop-магазине и цена.
Способ внесения запроса в БД PrestaSop'а - также на Ваш выбор: можете использовать удаленную консоль для подключения к БД магазина или запуск phpMyAdmin напрямую у хостера. Это на Ваше усмотрение.
Как работать (для удобства колонки и ячейки, в которых необходимы изменения, выделены желтым цветом):
1. Открываете свой прайс-лист.
2. Копируете колонку с кодами артикулов для магазина в скачаный документ, лист "Прайс", столбец "1".
3. Копируете колонку с ценами для магазина в прилагаемый документ, лист "Прайс", столбец "4".
4. Переходите в лист "Shop". Редактируете префикс БД PrestaShop'а.
5. Там же. Редактируете процент налога. (у меня 20% - т.е. 0.2)
6. Там же. Если необходимо , редактируете "Округление" - число знаков после запятой в БД PrestaShop. Но я бы советовал, чтобы избежать сложностей в жизни, использовать цены, кратные налогу. Да и клиенту проще. Пусть лучше цена будет на пару копеек/центов выше, зато не будет вопросов от умников, у которых цена за 1 позицию товара "11.37" - это округление от "11.36666666666", а сумма за 10 штук с налогом будет 136.40, а не 136.44. Внимание! Разделитель целой/дробной части точка, а не запятая. И перед редактированием сначала уточните точность в БД.
7. Распространяете формулы расчетов до необходимого размера вашего прайс-листа (выделяете последнюю строку расчета, начиная с колонки "3" листа "Shop" и тянете мышкой за нижнюю правую черную точку выделенной области)
8. В колонке "Результат" - зеленая - получаете SQL-запрос для обновления цен в БД PrestaSop'a.
Лист "Экспорт цен из PrestaShop" и колонки "Эти поля используются для проверки цен после отработки запроса" в листе "Shop" используются для проверки корректности внесения цен.
Весь процесс, после изучения механизма, работает достаточно быстро и четко. Несоответствие цен (или невозможность внести их в магазин) возможна в следующих случаях:
- наличие индивидуальных скидок для клиентов или товара, которые любят демонстрировать на сайте отдельной строкой (типа стоило 80, Ваша цена 76) - в 1С такого просто нет
- неправильное или неполное заполнение опций (атрибутов) товара в магазине, что не дает возможность его однозначно идентифицировать. Например, указан артикул для товара, а цена задана лишь для его опции.
Под индивидуальными скидками в 1С имелось ввиду не % скидки/наценки от общего прайс-листа, а специальная цена, обусловленная договором с клиентом, которая задается априори или вычисляется каким-то особенным способом (например, есть покупатель-банк, с которым цены оговорены изначально в у.е. и текущая цена за товар рассчитывается по следующей формуле: 15% от оговоренной в договоре цена товара + 85% от нее же, умноженной на отношение текущего курса валюты этого банка к курсу валюты на день подписания в день зачисления средств. Согласитесь, в Экселе это рассчитать быстрее и проще, чем в Престе или в 1С).
В любом случае, этот механизм не универсален, а просто описывает метод, который можно использовать для упрощения своей жизни.
На текущий момент обслуживается 3 магазина. В представленном примере 300 товаров, что вместе с опциями дает около 1000 позиций. Примерно 80% товаров автоматически обновляются и автоматически проверяются на соответствие цены. Еще примерно 15% - это опции, у которых есть небольшие корреляции цены, в зависимости от атрибутов (цвет, особенность изготовления, тип упаковки и т.д.). Для них я бы рекомендовал просто сделать пометку на полях листа "Shop" - "опция" или использовать отдельный лист/запрос для проверки.
Оставшиеся 5% - да, ручками, т.к. есть желание показать скидки, как приманку для клиента. В любом случае, проверить и подкорректировать цены/скидки 20 опций товара (а это всего 4 позиции) гораздо быстрее и проще, чем 1000.
