- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Уже звучала мысль, подчеркну: проблема создана искусственно, в результате скрещивания двух систем. Получаются этакие сиамские близнецы, или змей-горыныч, или лебедь, рак и щука.
Надо выкинуть что-то, и работать в одном. А другая часть будет лишь фронт-эндом, и не надо никаких синхронизаций. Пилить что-то одно до победного конца.
Я сторонник другого подхода. Сейчас интернет доступен достаточно хорошо. И я делаю онлайн-систему для всех участков склада. Не важно откуда оформляется заказ: из дома клиентом, из нашего офиса оператором, на складе или еще как. Все оформляется через сайт, там же ведется весь учет. И наличие на складе меняется онлайн, чтобы не мог клиент успеть заказать товар, который фактически уже отсутствует или в резерве.
Я сторонник другого подхода. Сейчас интернет доступен достаточно хорошо. И я делаю онлайн-систему для всех участков склада. Не важно откуда оформляется заказ: из дома клиентом, из нашего офиса оператором, на складе или еще как. Все оформляется через сайт, там же ведется весь учет. И наличие на складе меняется онлайн, чтобы не мог клиент успеть заказать товар, который фактически уже отсутствует или в резерве.
Для такого подхода у Вас должен быть отказоустойчивый хостинг + защита от DDOS. Иначе чуть что у Вас вообще вся работа встанет...
zaka4ek
Есть свой сервер + несложно докупить еще один и сделать онлайн-резервирование.
Более того, основной сервер за пределами России, для того, дополнительная защита от конкурентов, чтобы не могли устроить выемку сервера.
Да и дублю системы на локальные ПК тоже можно делать без особых проблем, тогда просто разорвется связь, и каждый снова начнет работать отдельно. Как и в случаях, которые описаны выше.
Сейчас интернет безлимитный, так что синхронизироваться информация может каждую минуту без напряга.
При таком подходе фронт можно менять и довольно кардинально по мере роста магазина, при это нет нужды делать какие-то мега-доработки. Просто меняется кусочек, отвечающий за синхронизацию с бэком и все. Так же никто не мешает иметь несколько магазинов и единую базу в учетной системе.
Я вот тоже хочу сделать такую систему не знаю с чего начать, в 1С не сильно шарю, наверно нужно ТЗ какое не будь написать или начать с бизнес процессов?
Я вот тоже хочу сделать такую систему не знаю с чего начать, в 1С не сильно шарю, наверно нужно ТЗ какое не будь написать или начать с бизнес процессов?
Тут много частностей:
- Насколько велика ваша компания, какими темпами она развивается сейчас и какой будет на протяжении следующих 2-3 лет? От этого зависит необходимый для реализации функционал.
- Есть ли какие-то бизнес-процессы, если есть - как они формализованы. 99,99% фирм (включая крупные и очень крупные) не имеют задокументированных бизнес-процессов, все делается "от балды". А от этого будет зависеть ТЗ и конечный продукт. Если фирма маленькая (человек до 20), забудьте все эти глупые слова, не до того. Есть текущая ситуация, некоторый опыт работы - поэтому крутимся в зависимости от ситуации.
- Я тоже в 1С "не сильно шарю", но начал потихоньку строить свой велосипед. Готовые вещи для маленького (как у меня) магазина не подходят либо из-за стоимости, либо из-за реализации. В данный момент делаю ТЗ и наброски "как оно должно все работать". Вариант привлечения внешних разработчиков пока что так же не подходит из-за цен на 1С специалистов. Делать магазин с реализацией функционала в бэкенде я не хочу по нескольким причинам, одна из которых 1С: какая бы это ни была уродливая штуковина, с ней умеет работать масса народу, ну и реализованный функционал в области учета меня устраивает.
- Жутко не люблю всякие велосипеды, самописные системы и так далее, но в данный момент не нашел никаких альтернатив, увы.
Поэтому решил начинать все с ноля.
По поводу надёжности сервера и канала — решает размещение на территории организации. Кому очень не нравятся самостийные хостинги, можно прикрутить отдельную веб-морду на нормальном хосте, берущую информацию с внутреннего сервера, чисто для клиентов. Как альтернатива и компромисс, проксирование.
Зря Вы так на 1с.
У меня 2 магазина, на обоих связка 1с-битрикс. В свое время решали Ваши проблемы за счет допиливания выгрузки и обмена.
Все решается, если захотеть.