Верно, я так и сделал. Изначально определился, что заказы идут с сайта в 1С. А из 1С на сайт идут остатки и цены.
Аналогично.
Точно так же.
Но, с появлением новых задач такая схема перестает работать гладко.
Пример: хочу подключить к выдаче заказов чужие ПВЗ.
У сторонних ПВЗ может 2 типа работы: просто выдача и выдача типа "полка", когда я арендую полку и оттуда отгружают товар по мере поступления заказов:
1. Просто выдача. Я привез товар, их точка выдала. Если покупатель не забрал, он возвращается назад.
У этого способа есть 3 разветвления: первое - покупатель просто пришел и забрал весь заказ.
Второе - покупатель хочет взять заказ частично и сторонний ПВЗ такую возможность предоставляет? Где редактировать заказ? В 1С или на сайте и потом передавать с сайта в 1С?
Третье - покупатель не забирает заказ. Где проводить отмену? ПРи этом, отмена в стороннем ПВЗ это не то же самое, что отмена в нашем ПВЗ и не то же самое, что отмена в ПВЗ типа "Полка".
Если мы отменяем заказ в таком ПВЗ, то мы не можем сразу пустить товар в продажу, он сначала должен приехать на наш склад. Где всё это проводить? В 1С или на сайте и потом это перемещение грузить в 1С?
2. Сторонний ПВЗ типа "Полка".
Делаем перемещение на соответствующий склад, коим у нас является эта точка ПВЗ и торгуем оттуда. Такой ПВЗ мы можем рассматривать как наш собственный склад.
Если мы делаем корректировки заказов в 1С, а не на сайте, тогда нам надо сначала загрузить заказы в 1С, провести все корректировки и только после этого мы можем выгрузить данные из 1С на сайт.
А, чтобы провести корректировки заказов в 1С кто-то должен постоянно в ней сидеть и это делать. Т.е. мы завязываемся на оператора. Если он что-то не забил на данный момент, то мы не можем даже выгрузить данные на сайт.
Я думал как сделать:
Вот есть заказ, он был сделан, допустим, 3 дня назад и уже загружен в 1С. Приходит покупатель и говорит: вот это уберите, а это добавьте.
Менеджер делает корректировку заказа на сайте, остатки при этом меняются. Он его отгружает, все довольны.
Загружает заказы в 1С. К этому заказу (на основании заказа), т.к. он ранее был загружен, в 1С автоматом создается документ "Корректировка заказа".
И тогда, и в 1С и на сайте одинаковые данные. Можно не ждать оператора 1С и выгрузить на сайт новые остатк и новые цены. Или вообще ничего не выгружать, т.к. остатки у нас одинаковые, если не было приходов товара, которые забиваются только в 1С, а не на сайте.
Но, при этой схеме возникает опять проблема сторонних ПВЗ. Ведь, там-то отмена заказа не должна приводить к изменению остатков. А если склад типа "Полка", то должна. Получается, на одном складе мы делаем так, на другом по другому, на третьем по третьему. Черт ногу сломит.
ЛОгичнее всё это делать в 1С. Но, тогда возникает проблема несоответствия данных в 1С и на сайте. На сайте всегда товара должно быть меньше или равно, чем в 1С, но никогда не больше, чтобы покупатель не мог заказать несуществующий товар.
Как сделаны корректировки у меня сейчас:
менеджер на сайте корректриует заказ, который ранее уже был загружен в 1С.
Пишет оператору 1С с помощью тикета: "такой-то заказ был откорректирован". Оператор при забитии, корректирует его в 1С.
Т.е. выполняется двойная работа.
Если заказ ранее не был загружен, то все проще: в 1С он загружается уже сразу откорректированным.
Почему нельзя с сайта корректировать заказы в 1С без тикетов оператору? Потому что опять таки, есть сторонние ПВЗ, на которых корректировка приводит к другим последствиям, чем корректировка заказа со своего склада. А оператор может произвести необходимые действия в 1С, чтобы остатки были корректными, а силами сайта этого не сделать, либо на сайте придется городить функционал 1С.
Управление торговлей 10.3.
Сорри, сначала не обратил внимание, что вопрос к colorito. Но, может и по мне что подскажете :)
Можно задачу свести к следующей:
надо на сайте публиковать данные из 1С в режиме онлайн. Т.е. есть база 1С она опубликована где-то в вебе, и сайт, для показа остатков и цен, берет данные оттуда. Без синхронизаций, без выгрузки, просто сайт напрямую смотрит в базу 1С и выводит инфу на сайте. А мы уже говорим что именно показывать: цена, наличие на определенном складе, резерв.
colorito, спасибо. Чего-то не очень тоже такой вариант. Хочется бОльшей автоматизации, и меньшей вероятности ошибок. А ваш вариант как мой, только у меня сайт главный в остатках и заказах, а у вас 1С. Но, обе схемы в определенной степени косячные.
Вот это интересно. Как реализовано? Базы общаются напрямую друг с другом? Посредством чего? Или вытягивают данные из одного источника?
Этот вопрос еще возник в связи с тем, что при моей схеме, на определенном этапе, слишком большая нагрузка ложится на оператора 1С, и надо или нанимать человека на бОльшее время работы, либо как-то автоматизировать этот процесс. Слишком много операций приходится дублировать.
Например, отмена заказа: менеджер на сайте отменил заказ, который лежит на стороннем ПВЗ. Остатки это увеличить не может, т.к. товар не у нас. Они отменяет его в админке и делает метку. Эту метку видит оператор 1С и отменяет заказ в 1С, но не делает перемещения между складами, чтобы товар не стал доступен к заказу. Потом надо вручную отследить перемещение товара из стороннего ПВЗ на наш склад. Работник склада вносит в отчет это перемещение. Операторо 1С видит его и забивает в 1С. После этого он выгружает остатки на сайт и только тогда товар попадает на наш склад и становится доступным к заказу.
Куча операций была продублирована. Оператор 1С сделал то же, что сделали менеджер и кладовщик в своих отчетах. Только они в отчетах, а он в 1С.
По идее надо, чтобы сам менеджер в 1С или на сайте сделал отмену и сам же сделал перемещение в 1С (или на сайте) и всё это сразу попало в 1С. Т.е. исключить оператора 1С из этой цепочки, т.к. он просто повторяет действия менеджера и работника склада.
Сорри, я решил, что вы заморочились этим, но не используете.
И сколько времени покупателю приходится ждать?
Речь не про отображение остатков, а про их актуальность на сайте. Это важнейшая вещь. Покупатель не должен иметь возможность заказать отсутсвующий товар.
Синхронизировать чаще, это не исключает проблему, а лишь снижает вероятность ее появления. Та схема, которая реализована сейчас у меня, эту проблему исключает, потому что сначала заказы идут на сайт и только оттуда в 1С. Т.е. на сайте товара не может быть больше, чем в 1С, только меньше или равно. Но, при такой схеме вылезают другие проблемы.
К тому же, что значит синхронизировать? Передавать заказы с сайта в 1с, а потом выгружать остатки на сайт?
ТОгда надо в 1С постоянно сидеть и в реалтайме делать коррекции заказов, проводить брак и тд (а брак могли менеджеры убрать на сайте из остатков вручную сразу после обнаружения, чтобы нельзя было заказать этот товар). Т,е. то, что делается фактически в этот момент на складе с товаром, иначе при выгрузке вы выгрузите всё это без этих изменений. Т.е. вы не можете отложить например проводку брака на вечер, т.к. если вы ее не забьете прямо сейчас, то вы не можете выгрузить остатки на сайт, у вас там будет лишний товар.
Это тоже плохо.
Понял.
Ну, скорее да, чем нет. Просто есть товары, которые в единичных экземплярах. И по закону подлости бывает, что заказывают их одновременно.
Ну, в общих чертах понял, спасибо. Вообщем, конечно, тоже не идеально реализовано.
Это хороший пример.
Т.е. вся работа с заказом ведется в 1С, а не на сайте?
А если покупатель в момент получения заказа хочет его изменить, продавец в 1с меняет его заказ?
Как вы это контролируете? Вот, захотел менеджер и изменил. Как сделать технически невозможной такую корректировку? Можно поставить запрет после какого-то статуса, но статусов наплодится такое к-во, что сам потом запутаешься. Несколько типов заказов, несколько статусов, всё это перемножится и возникнет огромное к-во комбинаций.
Да, вот это мне и не нравится больше всего в схеме, где 1С главная. Т.е. остатки на сайте не соответствуют реальным. А если сделать главным в этой связке сайт, а не 1С, то надо на сайте так мудрить, чтобы всё, что надо передавалось в 1с, и эта задача становится подобна написанию новой СРМ.
А еще есть усложнение: сторонние ПВЗ, на которых отмена заказа еще не означает, что товар доступен к продаже. А еще дальше: ПВЗ типа "Полка". Когда этот ПВЗ сторонний, но отмена дает возможность заказать этот товар другому покупателю.
Не представляю как так работать. Я бы места себе не находил от ощущения, что я не контролирую ситуацию.
2 рубля почти, но зато доходит.
Я юзаю СМСинтел. Перешел на них с СМС.ру Уже год наверное, всё норм.
Для рекламных рассылок, мне кажется это нормально, что никто не зашел :) И да, прямые каналы вам не подойдут, просто конверсия не окупит стоимость этих СМС.
У меня только транзакционные.
А они пишут статус сообщений в ЛК?
DenisVS, ну это гимор, так настраивать. Надо быть энтузиастом этого дела, ну как минимум ИТшником )
Потому что прожорливость все равно приведет к тормозам. Либо вынудит начинать гонку вооружений: каждая новая версия всё прожорливее и рано или поздно приходится менять железо. Из-за браузера. Т.к. остальные проги не жрут особо. Именно браузеры заставляют покупать болще РАМ, быстрее ХДД и прочее.
Да уж...
А есть нормальные браузеры-то тогда?
