Где в России недорогие системы автоматизации бизнес-процессов?

А номера заказов у Вас из битрикса тянутся или присваиваются 1С.? тогда получается клиенту на сайте один номер заказа выдается, а оператор видит другой.

И если операторы заводят заказы поступающие в 1С, как идет расчет стоимости доставки и оплаты, если покупатель например просит выслать квитанцию или выставить счет через терминалы qiwi???

Интересует вопрос про номера заказов!

Вы слишком всё усложнили. Все эти проблемы решаются 1с-ником или ПХП-шником с опытом.

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

По ИНН - физ лицу присваивайте ИНН равный номеру телефона(реализуется на сайте, за 5 минут).

Номер заказа с сайта отдавайте в 1С в виде комментария.

Номер заказа и так передается. С этим проблем нет. Проблема в том, что если покупатель при оформлении выбирает оплата по счету то номер счета выставляется по номеру заказа. Если при выгрузке заказа в 1С документ заказа нумеровать не по номеру заказа из Битрикса, то номера счетов не будут совпадать, поэтому получается при печати документов опять придется лезть в Битрикс...

у меня в 1с-ку номер заказа приходит в виде комментария.

---------- Добавлено 20.09.2012 в 22:19 ----------

Я могу и из 1С выставить - руками, а в битрикс выставляется автоматом после оформления заказа... В принципе этот функционал не сложно перенести в 1С, чтобы после соглавания заказа счет в pdf автоматом отправлялся на почту клиенту...

1С -ка умеет сама письма рассылать, счет может автоматом из 1С уйти, через ее внутреннюю почту.

superf, А Вы писали какую доработку для операторов для оформления нового заказа? Или стандартными средствами сначала заводят партнера, потом контрагента, потом форму заказа заполняют, имхо - слишком много времени на это уходит...

--а что такое заводят партнера?

---------- Добавлено 20.09.2012 в 23:00 ----------

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

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

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

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

Т.е. магазин - работа с пользователями, учетная система - вся внутренняя кухня.

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