Форум
Читайте нас также:

об электронной торговле - для интернет-магазинов и ритейла. портал и сообщество

Форум

Автоматизация Интернет-магазина (минимум 1С)



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Intuitsiya:

Кто подскажет: хочется выгружать номенклатуру из 1С на сайт по расписанию, напр.1 или 2 р. в день. Но много заказов, которые находятся в статусе "отложен , но неоплачен", соотвественно в 1С они не проведены - не оформленая "реализация товаров". Естественно выгрузка целой категории будет некорректна. Как с этим бороться?


Можно вести весь учет в интернет-магазине, и в конце дня выгружать данные в 1С-Бухгалтерию для выполнения бухгалтерских проводок.

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



Ссылка на сообщение Intuitsiya


Проблема в том, что весь учет ведется в 1С УТ, заказы сразу загружаются в 1С, меняются статусы, отправляется инфа клиентам,а через админку Им, к сожалению, вести нереально. В конце дня - не получается, т.к. статус "Не оплачен" может быть несколько дней, пока придут деньги на р/с и т.д и т.п. А каждый день поступает новый товар, который нужно выгружать из 1с на сайт, при том что остатки в Им всегда должны быть актуальна. Так что пока не разберусь....



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Intuitsiya:

Проблема в том, что весь учет ведется в 1С УТ


Вот именно, проблема как раз в этом.
Гораздо удобнее создать интегрированное решение, на выходе которого получается только информация для бухгалтерии.

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



Ссылка на сообщение Intuitsiya


Цитата:

Вот именно, проблема как раз в этом.
Гораздо удобнее создать интегрированное решение, на выходе которого получается только информация для бухгалтерии.

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

Это на самом деле не совсем проблема) В 1с, особенно в Торговле держать базу гораздо удобнее и надежнее, чем на стороннем сервере, в Им. Доработка 1С гораздо дешевле, чем "движка", по которому очень сложно найти адекватного специалиста. Проверено)
В моем случае оказалась все проще -необходима небольшая доработка, которая позволит выгружать на сайт новый товар, учитывая тот, который еще не оплачен.



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Intuitsiya:

1с, особенно в Торговле держать базу гораздо удобнее и надежнее, чем на стороннем сервере, в Им. Доработка 1С гораздо дешевле, чем "движка", по которому очень сложно найти адекватного специалиста.


Ну тут как бы оба утверждения спорны.

Что касается удобства с точки зрения возможности учета движения товаров и заказов в реальном времени, то удобнее когда база интернет-магазина и учетной система одна. Иначе может получиться рассогласование, "расщепление мозга".

По надежности - зависит от того, как обстоит дело с надежностью. Сервер 1С может быть гораздо менее надежен серевера интернет-магазина и наоборот.

Что же касается адекватного специалиста - обращайтесь непосредственно к разработчикам ПО для интернет-магазинам, а не к посредникам и фрилансерам. Разработчик обладает адекватным знанием своего ПО и возможностями его развития.

Intuitsiya:

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


Конечно, тут все зависит от требований. Если нет требования учета движения товаров в реальном времени, можно обойтись и выгрузками. Но тогда трудно показывать на витрине информацию о реальном наличии товара, например.



Ссылка на сообщение Intuitsiya


Александр Фролов:

Что касается удобства с точки зрения возможности учета движения товаров и заказов в реальном времени, то удобнее когда база интернет-магазина и учетной система одна. Иначе может получиться рассогласование, "расщепление мозга".

У меня система единая- все движение в реальном времени и нет никаких задвоений. На сайте всегда актуальные остатки. Иногда бывает сбой, если выгрузился не проведенный по базе товар - о чем я писала выше.
Цитата:

По надежности - зависит от того, как обстоит дело с надежностью. Сервер 1С может быть гораздо менее надежен серевера интернет-магазина и наоборот.

Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Цитата:

Что же касается адекватного специалиста - обращайтесь непосредственно к разработчикам ПО для интернет-магазинам, а не к посредникам и фрилансерам. Разработчик обладает адекватным знанием своего ПО и возможностями его развития.

Это естественно. Но, к сожалению, иногда и они не могут помочь, т.к. возможности продукта ограничены. Фрилансеров вообще не обсуждаю.

Цитата:

Конечно, тут все зависит от требований. Если нет требования учета движения товаров в реальном времени, можно обойтись и выгрузками. Но тогда трудно показывать на витрине информацию о реальном наличии товара, например.

В реальном времени-это обязательное условие. Просто при выгрузке не будет "захвата" товара, который находится в резерве)



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Intuitsiya:

Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...

Intuitsiya:

У меня система единая- все движение в реальном времени и нет никаких задвоений. На сайте всегда актуальные остатки. Иногда бывает сбой, если выгрузился не проведенный по базе товар - о чем я писала выше.


А у Вас в интернет-магазине своя база данных, а в 1С - своя?

Например, посетитель оформил заказ, и данный товар на складе закончился. А через секунду другой посетитель оформил заказ на тот же товар. Товара уже нет, он был распродан секунду назад, посетитель об этом узнает?

Т.е. действительно ли у Вас реальное время?

Intuitsiya:

Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...


Надежность, вернее, оказоустойчивость - вопрос не простой. Решается практически однинаково и для локальных серверов, которые стоят в офисе, и для серверов интернет-магазинов, размещенных на площадке провайдера.

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

Необходим постоянный мониторинг загрузки и состояния серверов, периодический контроль уязвимостей и обновление версий ПО.

Надежность зависит в первую очередь от системного архитектора и системного администратора. Но еще важен и бюджет. по-настоящему отказоустойчивые решения стоят дорого.

Intuitsiya:

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


Разработчик всегда может расширить возможности своего продукта. Вот у нас, например, есть заказные решения, возможности которых ничем не ограничены. В них нет ничего такого, что наши специалисты не могли бы усовершенствовать, т.к. они сами все и создавали.

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

Intuitsiya:

В реальном времени-это обязательное условие. Просто при выгрузке не будет "захвата" товара, который находится в резерве)


Ну вот, в этой ситуации и сказыватся преимущества интегрированных систем. Например, магазин может резервировать товары под заказы в реальном времени на складе, отслеживать движение товаров в настоящем реальном времени по виртуальным и реальным складам, показывать реальное наличие с учетом текущего состояния всех складов.

А вот информацию, необходимую для бух. учета, можно выгружать и в конце дня, т.к. тут не нужно реального времени.

В интегрированных системах нет никаких критических выгрузок, и нет проблем синхронизации, которые с ними связаны.



Ссылка на сообщение Intuitsiya


Цитата:

Например, посетитель оформил заказ, и данный товар на складе закончился. А через секунду другой посетитель оформил заказ на тот же товар. Товара уже нет, он был распродан секунду назад, посетитель об этом узнает?

Т.е. действительно ли у Вас реальное время?

Да, второй уже не сможет сделать заказ


Цитата:

Надежность, вернее, оказоустойчивость - вопрос не простой. Решается практически однинаково и для локальных серверов, которые стоят в офисе, и для серверов интернет-магазинов, размещенных на площадке провайдера.

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

Необходим постоянный мониторинг загрузки и состояния серверов, периодический контроль уязвимостей и обновление версий ПО.

Надежность зависит в первую очередь от системного архитектора и системного администратора. Но еще важен и бюджет. по-настоящему отказоустойчивые решения стоят дорого.

Интересная информация. Но по-моему, это больше актуально для крупного бизнеса, для малого -тут как то все по-проще)

Цитата:

Разработчик всегда может расширить возможности своего продукта. Вот у нас, например, есть заказные решения, возможности которых ничем не ограничены. В них нет ничего такого, что наши специалисты не могли бы усовершенствовать, т.к. они сами все и создавали.

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

Тут мы намек поняли) Но движок очень популярен среди Им и тем не менее очень мало адекватных программистов. А как быть с эксклюзивными, уникальными решениями или самописными движками? Кто потом будет разбираться в них?
Цитата:

Ну вот, в этой ситуации и сказыватся преимущества интегрированных систем. Например, магазин может резервировать товары под заказы в реальном времени на складе, отслеживать движение товаров в настоящем реальном времени по виртуальным и реальным складам, показывать реальное наличие с учетом текущего состояния всех складов.

А вот информацию, необходимую для бух. учета, можно выгружать и в конце дня, т.к. тут не нужно реального времени.

В интегрированных системах нет никаких критических выгрузок, и нет проблем синхронизации, которые с ними связаны.

Опять таки все это крутится на хостинге провайдера, ведь так? А тут все действительно неоднозначно...



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Intuitsiya:

Интересная информация. Но по-моему, это больше актуально для крупного бизнеса, для малого -тут как то все по-проще)


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

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

Intuitsiya:

Но движок очень популярен среди Им и тем не менее очень мало адекватных программистов. А как быть с эксклюзивными, уникальными решениями или самописными движками? Кто потом будет разбираться в них?


Насчет того что трудно найти адекватных программистов, я с Вами полностью согласен. У нас постоянно открыты вакансии программистов, но найти новых сотрудников не просто...

Что касается эксклюзивных решений, то тут важно, кто их создавал. Если это гений-одиночка или компания, состоящая из 2-3 человек, то плохо. Если же ИТ-комания уже несколько лет на рынке, у нее много сотрудников (и не только программистов), сотни постоянных клиентов, то ситуация гораздо надежнее.

Intuitsiya:

Опять таки все это крутится на хостинге провайдера, ведь так? А тут все действительно неоднозначно...


Если Вы покупаете "движок", то да, Вам придется искать еще и адекватный хостинг.

А у нас нет, т.к. мы сами провайдеры с лицензией на телематику, и от провайдеров верхнего уровня нам нужны только каналы в Интернет.

Мы не размещаем на наших серверах что попало, только интернет-магазины и только созданные на базе нашего собственного ПО. Это позволяет нам лучше контролировать нагрузку и стабильность работы серверов.

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

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

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

В этом преимущество сервисов, подобных нашему - относительно недорого можно получить в пользование довольно сложное решение, размещенное на надежном, а главное, специализированном хостинге.



Ссылка на сообщение Joker120712


Intuitsiya:

Да, второй уже не сможет сделать заказ

Скажите пожалуйста, у Вас идет зарузка товара
в БД сайта из 1С или сами вводите invoice, и если я правильно понял, то 1с для вас - складское приложение (клиентов менеджеры также ведут в БД Сайта ?); или БД сайта - торговая площадка (оприходование и продажа товара, проверка наличия оплаты и т.д. - максимум география клиентов и как они платят).
И еще вопрос на складе есть товар, я его заказываю и плачу своей картой (какое то время у Вас уйдет на проверку моей карты (остаток на счете, факт оплаты), как быть с покупателем, заказавшим тот же товар через секунду ? ) :D



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Joker120712:

на складе есть товар, я его заказываю и плачу своей картой (какое то время у Вас уйдет на проверку моей карты (остаток на счете, факт оплаты), как быть с покупателем, заказавшим тот же товар через секунду ? )


Вот для решения этой проблемы и нужна система реального времени. Здесь можно непосредственно перед оплатой зарезервировать товар на складе, и тогда его нельзя будет оплатить два раза.

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

Всякие схемы синхронизации базы данных магазина и складской базы 1С могут вызывать проблемы с таким резервированием. Особенно, если синхронизация выполняется периодически, хоть даже и ежеминутно.



Ссылка на сообщение Joker120712


Александр Фролов:

Вот для решения этой проблемы и нужна система реального времени. Здесь можно непосредственно перед оплатой зарезервировать товар на складе, и тогда его нельзя будет оплатить два раза

Спасибо, понятно как работает Ваша система, что до синхронизации - на самом деле это делается и успешно
работает, но естественно в рамках бизнеспрцесса портала (интернет магазина); ревизию остатков склада положено проводить каждый месяц, а для склада да и управленческого учета лучше подойдет 1С.
Спасибо за ответ, остался еще один вопрос - вдение клиентов поностью в БД сайта ?



Ссылка на сообщение Александр Фролов,
Управляющий директор Shop2YOU
Москва


Joker120712:

остался еще один вопрос - вдение клиентов поностью в БД сайта


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

Конечно, если у Вас уже построена инфраструктура на базе 1С, вложено много денег в продукты 1С и их настройку, в обучение сотрудников работе с этой системой, то, возможно, лучше идти по пути интеграции с сайтом магазина. Но нам, как разработчикам, проще реализовывать все у себя, а не решать проблемы интеграции разнородных систем.



Ссылка на сообщение Joker120712


Александр Фролов:

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

Тогда если я правильно понял, логистика у Вас тоже
зашита в Вашу БД - (выписка путевок, ТТН, учет бензина, выдача денег из кассы курьерам, соответсвенно и расчет З/П, курьеров и водителей ?)



Ссылка на сообщение Joker120712


Joker120712:

расчет З/П, курьеров и водителей ?

Под расчетом З/П имелся в виду учет рабочего времени и по каки тарифам это должно учитываться






Ответить



:D
:)
:(
:o
:shock:
:?
8)
:lol:
:x
:P
:oops:
:cry:
:evil:
:twisted:
:roll:
:wink:
:!:
:?:
:idea:
:arrow:
:|
:mrgreen:







2001 - 2017 © Оборот.ру. Все права защищены