Комментарии 4
Полный импорт без цен с остатками (собрать цены в 1С достаточно длительный процесс, т.к. только к нам на сайт импортируется 66 типов цен, поэтому импорт цен сделали опциональным).
Расскажите, пожалуйста, в каких случаях нужно 66 типов цен импортировать на сайт? Можно ли число 66 значительно уменьшить, импортируя базовые цены, при этом в отображаемом списке корректировать их, учитывая id клиента, объемы и т.д. Или это добавляло больше минусов, чем плюсов?
Вспомнил свой опыт по работе с 1С и со стороны заказчика, и со стороны исполнителя. Несмотря на все косяки со стороны 1С и их франчайзи, больше всего головной боли возникало из-за "человеческого фактора": особенностей работы отдела продаж, особых представлений главбуха...
Как-то накануне Нового года переводили организацию с 1С 7.7 на 8.1 и УТ с последующей веб-интеграцией. Хотелки бухгалтерии были такие: сделайте так, чтоб для нас ничего не поменялось. При этом они привыкли в половине случаев для каждого прихода одного и того же товара создавать новую номенклатуру. В итоге лишь через собственника удалось убедить, что правильнее не переносить бардак в новую систему. Пришлось бухгалтерии пару новогодних дней попотеть, но при этом складские остатки перенеслись чисто в новую систему в новом году, а номенклатура стала внезапно в несколько раз меньше, что позволило работать со складом нормально всем, а не только бухгалтеру, знающему чем Прибор Х отличается от Прибор "Х". Это я всё к тому, что если стандартные решения не подходят, то зачастую дело действительно в бизнес-процессах.
66 типов – это полный набор возможных вариаций, они считаются и хранятся на стороне 1С. отличаются по регионам, складам, типам покупателей (у нас и оптовики, и реселлеры тоже работают)
считать часть математики на стороне 1С, а часть в вебе мы считаем довольно опасной практикой (если не брать простейшие штуки типа скидки на сумму заказа, которая считается в корзине)
причем 66 это еще не так много, бывают проекты, где например 1000 типов цен, что на 10000 товаров дает 10 млн значений, которые постоянно меняются
архитектурно красивого решения, если разделять процесс ценообразования и процесс продаж между системами, нет
вы правы, что особенности бизнеса очень влияют на возможность применения стандартных инструментов
postgre в БД новых сайтов сайтов.
Опечатка?
Общая трудоемкость в 500 часов не столь страшна
Конечно не страшна, сколько стоит час?
И если ваши (рекламные?) статьи для потенциальных клиентов то клиенту будет "ничегонепонятно". Если статьи для "погромистов 1С" то или мало деталей, или статью можно сократить до "Мы тут обмен ваяли, нестандартный. Получилось.".
статья и так на 10 тысяч знаков, и это часть серии. мне думается что подход, оценки, риски и критерии выбора мы рассказали. Если хотите прочитать огромный лонгрид буквально с указаниями как что настраивать – мы готовим следующую статью серии, возможно вам понравится
500 часов программиста это примерно 3-4 ч-месяца работы, сколько это стоит – думаю всем кому нужно и так известно
если нужно что-то рассказать подробнее, скажите конкретно
мы считаем что статья пишется для людей, которые способны сделать реализацию CRUD без наших подсказок, и общую логику обмена люди понимают исходя из особенностей проекта
Tutorial по обмену сайта с 1С. Часть вторая: зачем и как писать свой обмен с нуля на очередях и REST API