03/05/2012
Intuitsiya:
Кто подскажет: хочется выгружать номенклатуру из 1С на сайт по расписанию, напр.1 или 2 р. в день. Но много заказов, которые находятся в статусе "отложен , но неоплачен", соотвественно в 1С они не проведены - не оформленая "реализация товаров". Естественно выгрузка целой категории будет некорректна. Как с этим бороться?
Кто подскажет: хочется выгружать номенклатуру из 1С на сайт по расписанию, напр.1 или 2 р. в день. Но много заказов, которые находятся в статусе "отложен , но неоплачен", соотвественно в 1С они не проведены - не оформленая "реализация товаров". Естественно выгрузка целой категории будет некорректна. Как с этим бороться?
Можно вести весь учет в интернет-магазине, и в конце дня выгружать данные в 1С-Бухгалтерию для выполнения бухгалтерских проводок.
Соответственно, статусы заказов будут отслеживаться в ПО магазина, а когда статус заказа будет такой, что нужно делать проводку, этот заказ попадет в ежедневную выгрузку для 1С-Бухгалтерии.
03/05/2012
Проблема в том, что весь учет ведется в 1С УТ, заказы сразу загружаются в 1С, меняются статусы, отправляется инфа клиентам,а через админку Им, к сожалению, вести нереально. В конце дня - не получается, т.к. статус "Не оплачен" может быть несколько дней, пока придут деньги на р/с и т.д и т.п. А каждый день поступает новый товар, который нужно выгружать из 1с на сайт, при том что остатки в Им всегда должны быть актуальна. Так что пока не разберусь....
03/05/2012
Intuitsiya:
Проблема в том, что весь учет ведется в 1С УТ
Проблема в том, что весь учет ведется в 1С УТ
Вот именно, проблема как раз в этом.
Гораздо удобнее создать интегрированное решение, на выходе которого получается только информация для бухгалтерии.
Если Вы уже крупно вложились в 1С, то нужно либо интегрировать с 1С сайт витрины магазина и доделывать нужный Вам функционал в 1С (для чего потребуются хорошие специалисты по 1С), либо создавать полностью интегрированное решение на другой платформе.
05/05/2012
Цитата:
Вот именно, проблема как раз в этом.
Гораздо удобнее создать интегрированное решение, на выходе которого получается только информация для бухгалтерии.
Если Вы уже крупно вложились в 1С, то нужно либо интегрировать с 1С сайт витрины магазина и доделывать нужный Вам функционал в 1С (для чего потребуются хорошие специалисты по 1С), либо создавать полностью интегрированное решение на другой платформе.
Вот именно, проблема как раз в этом.
Гораздо удобнее создать интегрированное решение, на выходе которого получается только информация для бухгалтерии.
Если Вы уже крупно вложились в 1С, то нужно либо интегрировать с 1С сайт витрины магазина и доделывать нужный Вам функционал в 1С (для чего потребуются хорошие специалисты по 1С), либо создавать полностью интегрированное решение на другой платформе.
Это на самом деле не совсем проблема) В 1с, особенно в Торговле держать базу гораздо удобнее и надежнее, чем на стороннем сервере, в Им. Доработка 1С гораздо дешевле, чем "движка", по которому очень сложно найти адекватного специалиста. Проверено)
В моем случае оказалась все проще -необходима небольшая доработка, которая позволит выгружать на сайт новый товар, учитывая тот, который еще не оплачен.
05/05/2012
Intuitsiya:
1с, особенно в Торговле держать базу гораздо удобнее и надежнее, чем на стороннем сервере, в Им. Доработка 1С гораздо дешевле, чем "движка", по которому очень сложно найти адекватного специалиста.
1с, особенно в Торговле держать базу гораздо удобнее и надежнее, чем на стороннем сервере, в Им. Доработка 1С гораздо дешевле, чем "движка", по которому очень сложно найти адекватного специалиста.
Ну тут как бы оба утверждения спорны.
Что касается удобства с точки зрения возможности учета движения товаров и заказов в реальном времени, то удобнее когда база интернет-магазина и учетной система одна. Иначе может получиться рассогласование, "расщепление мозга".
По надежности - зависит от того, как обстоит дело с надежностью. Сервер 1С может быть гораздо менее надежен серевера интернет-магазина и наоборот.
Что же касается адекватного специалиста - обращайтесь непосредственно к разработчикам ПО для интернет-магазинам, а не к посредникам и фрилансерам. Разработчик обладает адекватным знанием своего ПО и возможностями его развития.
Intuitsiya:
В моем случае оказалась все проще -необходима небольшая доработка, которая позволит выгружать на сайт новый товар, учитывая тот, который еще не оплачен.
В моем случае оказалась все проще -необходима небольшая доработка, которая позволит выгружать на сайт новый товар, учитывая тот, который еще не оплачен.
Конечно, тут все зависит от требований. Если нет требования учета движения товаров в реальном времени, можно обойтись и выгрузками. Но тогда трудно показывать на витрине информацию о реальном наличии товара, например.
05/05/2012
Александр Фролов:
Что касается удобства с точки зрения возможности учета движения товаров и заказов в реальном времени, то удобнее когда база интернет-магазина и учетной система одна. Иначе может получиться рассогласование, "расщепление мозга".
Что касается удобства с точки зрения возможности учета движения товаров и заказов в реальном времени, то удобнее когда база интернет-магазина и учетной система одна. Иначе может получиться рассогласование, "расщепление мозга".
У меня система единая- все движение в реальном времени и нет никаких задвоений. На сайте всегда актуальные остатки. Иногда бывает сбой, если выгрузился не проведенный по базе товар - о чем я писала выше.
Цитата:
По надежности - зависит от того, как обстоит дело с надежностью. Сервер 1С может быть гораздо менее надежен серевера интернет-магазина и наоборот.
По надежности - зависит от того, как обстоит дело с надежностью. Сервер 1С может быть гораздо менее надежен серевера интернет-магазина и наоборот.
Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Цитата:
Что же касается адекватного специалиста - обращайтесь непосредственно к разработчикам ПО для интернет-магазинам, а не к посредникам и фрилансерам. Разработчик обладает адекватным знанием своего ПО и возможностями его развития.
Что же касается адекватного специалиста - обращайтесь непосредственно к разработчикам ПО для интернет-магазинам, а не к посредникам и фрилансерам. Разработчик обладает адекватным знанием своего ПО и возможностями его развития.
Это естественно. Но, к сожалению, иногда и они не могут помочь, т.к. возможности продукта ограничены. Фрилансеров вообще не обсуждаю.
Цитата:
Конечно, тут все зависит от требований. Если нет требования учета движения товаров в реальном времени, можно обойтись и выгрузками. Но тогда трудно показывать на витрине информацию о реальном наличии товара, например.
Конечно, тут все зависит от требований. Если нет требования учета движения товаров в реальном времени, можно обойтись и выгрузками. Но тогда трудно показывать на витрине информацию о реальном наличии товара, например.
В реальном времени-это обязательное условие. Просто при выгрузке не будет "захвата" товара, который находится в резерве)
05/05/2012
Intuitsiya:
Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Intuitsiya:
У меня система единая- все движение в реальном времени и нет никаких задвоений. На сайте всегда актуальные остатки. Иногда бывает сбой, если выгрузился не проведенный по базе товар - о чем я писала выше.
У меня система единая- все движение в реальном времени и нет никаких задвоений. На сайте всегда актуальные остатки. Иногда бывает сбой, если выгрузился не проведенный по базе товар - о чем я писала выше.
А у Вас в интернет-магазине своя база данных, а в 1С - своя?
Например, посетитель оформил заказ, и данный товар на складе закончился. А через секунду другой посетитель оформил заказ на тот же товар. Товара уже нет, он был распродан секунду назад, посетитель об этом узнает?
Т.е. действительно ли у Вас реальное время?
Intuitsiya:
Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Каким образом? Главное, по-моему, сохранность базы, а она бэкапится ежедневно. При желании ведь можно выгрузить на любой сайт)А если сайт "грохнут" или еще что-то с ним произойдет? Действительно интересно ...
Надежность, вернее, оказоустойчивость - вопрос не простой. Решается практически однинаково и для локальных серверов, которые стоят в офисе, и для серверов интернет-магазинов, размещенных на площадке провайдера.
Способы повышения отказоустойчивости: избыточность и еще раз избыточность. По минимуму два сервера, репликация данных, RAID-массивы, многоуровневое резервное копирование данных с хранением каждой ежедневной копии как минимум неделю (т.к. проблемы с данными могут быть замечены не сразу), и так далее, и много еще чего.
Необходим постоянный мониторинг загрузки и состояния серверов, периодический контроль уязвимостей и обновление версий ПО.
Надежность зависит в первую очередь от системного архитектора и системного администратора. Но еще важен и бюджет. по-настоящему отказоустойчивые решения стоят дорого.
Intuitsiya:
Но, к сожалению, иногда и они не могут помочь, т.к. возможности продукта ограничены.
Но, к сожалению, иногда и они не могут помочь, т.к. возможности продукта ограничены.
Разработчик всегда может расширить возможности своего продукта. Вот у нас, например, есть заказные решения, возможности которых ничем не ограничены. В них нет ничего такого, что наши специалисты не могли бы усовершенствовать, т.к. они сами все и создавали.
Другое дело, что иногда компании ориентируются на создание одной какой-либо версии "движка", максимально универсальной. Это обходится дешевле, чем сопровождение и развитие многих нестандартных версий. Так что выбирайте такую компанию, которая предлагает много существенно разных и сложных решений, а не один движок.
Intuitsiya:
В реальном времени-это обязательное условие. Просто при выгрузке не будет "захвата" товара, который находится в резерве)
В реальном времени-это обязательное условие. Просто при выгрузке не будет "захвата" товара, который находится в резерве)
Ну вот, в этой ситуации и сказыватся преимущества интегрированных систем. Например, магазин может резервировать товары под заказы в реальном времени на складе, отслеживать движение товаров в настоящем реальном времени по виртуальным и реальным складам, показывать реальное наличие с учетом текущего состояния всех складов.
А вот информацию, необходимую для бух. учета, можно выгружать и в конце дня, т.к. тут не нужно реального времени.
В интегрированных системах нет никаких критических выгрузок, и нет проблем синхронизации, которые с ними связаны.
05/05/2012
Цитата:
Например, посетитель оформил заказ, и данный товар на складе закончился. А через секунду другой посетитель оформил заказ на тот же товар. Товара уже нет, он был распродан секунду назад, посетитель об этом узнает?
Т.е. действительно ли у Вас реальное время?
Например, посетитель оформил заказ, и данный товар на складе закончился. А через секунду другой посетитель оформил заказ на тот же товар. Товара уже нет, он был распродан секунду назад, посетитель об этом узнает?
Т.е. действительно ли у Вас реальное время?
Да, второй уже не сможет сделать заказ
Цитата:
Надежность, вернее, оказоустойчивость - вопрос не простой. Решается практически однинаково и для локальных серверов, которые стоят в офисе, и для серверов интернет-магазинов, размещенных на площадке провайдера.
Способы повышения отказоустойчивости: избыточность и еще раз избыточность. По минимуму два сервера, репликация данных, RAID-массивы, многоуровневое резервное копирование данных с хранением каждой ежедневной копии как минимум неделю (т.к. проблемы с данными могут быть замечены не сразу), и так далее, и много еще чего.
Необходим постоянный мониторинг загрузки и состояния серверов, периодический контроль уязвимостей и обновление версий ПО.
Надежность зависит в первую очередь от системного архитектора и системного администратора. Но еще важен и бюджет. по-настоящему отказоустойчивые решения стоят дорого.
Надежность, вернее, оказоустойчивость - вопрос не простой. Решается практически однинаково и для локальных серверов, которые стоят в офисе, и для серверов интернет-магазинов, размещенных на площадке провайдера.
Способы повышения отказоустойчивости: избыточность и еще раз избыточность. По минимуму два сервера, репликация данных, RAID-массивы, многоуровневое резервное копирование данных с хранением каждой ежедневной копии как минимум неделю (т.к. проблемы с данными могут быть замечены не сразу), и так далее, и много еще чего.
Необходим постоянный мониторинг загрузки и состояния серверов, периодический контроль уязвимостей и обновление версий ПО.
Надежность зависит в первую очередь от системного архитектора и системного администратора. Но еще важен и бюджет. по-настоящему отказоустойчивые решения стоят дорого.
Интересная информация. Но по-моему, это больше актуально для крупного бизнеса, для малого -тут как то все по-проще)
Цитата:
Разработчик всегда может расширить возможности своего продукта. Вот у нас, например, есть заказные решения, возможности которых ничем не ограничены. В них нет ничего такого, что наши специалисты не могли бы усовершенствовать, т.к. они сами все и создавали.
Другое дело, что иногда компании ориентируются на создание одной какой-либо версии "движка", максимально универсальной. Это обходится дешевле, чем сопровождение и развитие многих нестандартных версий. Так что выбирайте такую компанию, которая предлагает много существенно разных и сложных решений, а не один движок.
Разработчик всегда может расширить возможности своего продукта. Вот у нас, например, есть заказные решения, возможности которых ничем не ограничены. В них нет ничего такого, что наши специалисты не могли бы усовершенствовать, т.к. они сами все и создавали.
Другое дело, что иногда компании ориентируются на создание одной какой-либо версии "движка", максимально универсальной. Это обходится дешевле, чем сопровождение и развитие многих нестандартных версий. Так что выбирайте такую компанию, которая предлагает много существенно разных и сложных решений, а не один движок.
Тут мы намек поняли) Но движок очень популярен среди Им и тем не менее очень мало адекватных программистов. А как быть с эксклюзивными, уникальными решениями или самописными движками? Кто потом будет разбираться в них?
Цитата:
Ну вот, в этой ситуации и сказыватся преимущества интегрированных систем. Например, магазин может резервировать товары под заказы в реальном времени на складе, отслеживать движение товаров в настоящем реальном времени по виртуальным и реальным складам, показывать реальное наличие с учетом текущего состояния всех складов.
А вот информацию, необходимую для бух. учета, можно выгружать и в конце дня, т.к. тут не нужно реального времени.
В интегрированных системах нет никаких критических выгрузок, и нет проблем синхронизации, которые с ними связаны.
Ну вот, в этой ситуации и сказыватся преимущества интегрированных систем. Например, магазин может резервировать товары под заказы в реальном времени на складе, отслеживать движение товаров в настоящем реальном времени по виртуальным и реальным складам, показывать реальное наличие с учетом текущего состояния всех складов.
А вот информацию, необходимую для бух. учета, можно выгружать и в конце дня, т.к. тут не нужно реального времени.
В интегрированных системах нет никаких критических выгрузок, и нет проблем синхронизации, которые с ними связаны.
Опять таки все это крутится на хостинге провайдера, ведь так? А тут все действительно неоднозначно...
06/05/2012
Intuitsiya:
Интересная информация. Но по-моему, это больше актуально для крупного бизнеса, для малого -тут как то все по-проще)
Интересная информация. Но по-моему, это больше актуально для крупного бизнеса, для малого -тут как то все по-проще)
Малый или крупный - это ведь все относительно. У нас подход к надежности серверов одинаковый и для крупного, и для малого бизнеса. Просто для крупных магазинов мы ставим выделенные серверы, а небольшие размещаем на наших серверах общего хостинга.
Потом, если не уделять внимание отказоустойчивости и нагрузочной способности, то магазин будет падать даже при слабых атаках или от поисковых роботов. Соответственно, если магазин работает плохо, малый бизнес рискует никогда не стать крупным)
Intuitsiya:
Но движок очень популярен среди Им и тем не менее очень мало адекватных программистов. А как быть с эксклюзивными, уникальными решениями или самописными движками? Кто потом будет разбираться в них?
Но движок очень популярен среди Им и тем не менее очень мало адекватных программистов. А как быть с эксклюзивными, уникальными решениями или самописными движками? Кто потом будет разбираться в них?
Насчет того что трудно найти адекватных программистов, я с Вами полностью согласен. У нас постоянно открыты вакансии программистов, но найти новых сотрудников не просто...
Что касается эксклюзивных решений, то тут важно, кто их создавал. Если это гений-одиночка или компания, состоящая из 2-3 человек, то плохо. Если же ИТ-комания уже несколько лет на рынке, у нее много сотрудников (и не только программистов), сотни постоянных клиентов, то ситуация гораздо надежнее.
Intuitsiya:
Опять таки все это крутится на хостинге провайдера, ведь так? А тут все действительно неоднозначно...
Опять таки все это крутится на хостинге провайдера, ведь так? А тут все действительно неоднозначно...
Если Вы покупаете "движок", то да, Вам придется искать еще и адекватный хостинг.
А у нас нет, т.к. мы сами провайдеры с лицензией на телематику, и от провайдеров верхнего уровня нам нужны только каналы в Интернет.
Мы не размещаем на наших серверах что попало, только интернет-магазины и только созданные на базе нашего собственного ПО. Это позволяет нам лучше контролировать нагрузку и стабильность работы серверов.
Что же касается хостингов общего пользования и виртуальных машин, и даже арендованных серверов, то тут да, ситуация с надежностью работы может оставлять желать лучшего.
Провайдеры общего назначения размещают на своих ресурсах всех подряд, и часто получается так, что либо хостинговые серверы перегружаются отдельными клиентами, либо провайдер автоматически отключает клиентов, создающих повышенную нагрузку. Качество серверов также может оставлять желать лучшего.
Когда-то давно я сам начинал с виртуальных хостингов, виртуальных серверов и арендованных физических серверов, так что знаю, о чем говорю. Теперь мы перешли полностью на собственное оборудование, далеко не самое дешевое, и администрирование собственными силами, и стало намного легче.
В этом преимущество сервисов, подобных нашему - относительно недорого можно получить в пользование довольно сложное решение, размещенное на надежном, а главное, специализированном хостинге.
12/07/2012
Intuitsiya:
Да, второй уже не сможет сделать заказ
Да, второй уже не сможет сделать заказ
Скажите пожалуйста, у Вас идет зарузка товара
в БД сайта из 1С или сами вводите invoice, и если я правильно понял, то 1с для вас - складское приложение (клиентов менеджеры также ведут в БД Сайта ?); или БД сайта - торговая площадка (оприходование и продажа товара, проверка наличия оплаты и т.д. - максимум география клиентов и как они платят).
И еще вопрос на складе есть товар, я его заказываю и плачу своей картой (какое то время у Вас уйдет на проверку моей карты (остаток на счете, факт оплаты), как быть с покупателем, заказавшим тот же товар через секунду ? )
13/07/2012
Joker120712:
на складе есть товар, я его заказываю и плачу своей картой (какое то время у Вас уйдет на проверку моей карты (остаток на счете, факт оплаты), как быть с покупателем, заказавшим тот же товар через секунду ? )
на складе есть товар, я его заказываю и плачу своей картой (какое то время у Вас уйдет на проверку моей карты (остаток на счете, факт оплаты), как быть с покупателем, заказавшим тот же товар через секунду ? )
Вот для решения этой проблемы и нужна система реального времени. Здесь можно непосредственно перед оплатой зарезервировать товар на складе, и тогда его нельзя будет оплатить два раза.
Под "непосредственно перед оплатой" я понимаю, что резервирование на складе должно быть выполнено в начале транзакции оплаты. Сперва резервируем, потом оплачиваем.
Всякие схемы синхронизации базы данных магазина и складской базы 1С могут вызывать проблемы с таким резервированием. Особенно, если синхронизация выполняется периодически, хоть даже и ежеминутно.
13/07/2012
Александр Фролов:
Вот для решения этой проблемы и нужна система реального времени. Здесь можно непосредственно перед оплатой зарезервировать товар на складе, и тогда его нельзя будет оплатить два раза
Вот для решения этой проблемы и нужна система реального времени. Здесь можно непосредственно перед оплатой зарезервировать товар на складе, и тогда его нельзя будет оплатить два раза
Спасибо, понятно как работает Ваша система, что до синхронизации - на самом деле это делается и успешно
работает, но естественно в рамках бизнеспрцесса портала (интернет магазина); ревизию остатков склада положено проводить каждый месяц, а для склада да и управленческого учета лучше подойдет 1С.
Спасибо за ответ, остался еще один вопрос - вдение клиентов поностью в БД сайта ?
13/07/2012
Joker120712:
остался еще один вопрос - вдение клиентов поностью в БД сайта
остался еще один вопрос - вдение клиентов поностью в БД сайта
Наши решения как раз и предполагают ведение клиентов и складского учета полностью в БД магазина. Аналогично там же - отчеты, статистика, документооборот, автоматический импорт товарных предложений от поставщиков и т.д. и т.п. Т.е. мы реализуем подход "все в одном", наружу - только экспорт данных для бухгалтерского учета.
Конечно, если у Вас уже построена инфраструктура на базе 1С, вложено много денег в продукты 1С и их настройку, в обучение сотрудников работе с этой системой, то, возможно, лучше идти по пути интеграции с сайтом магазина. Но нам, как разработчикам, проще реализовывать все у себя, а не решать проблемы интеграции разнородных систем.
13/07/2012
Александр Фролов:
Наши решения как раз и предполагают ведение клиентов и складского учета полностью в БД магазина. Аналогично там же - отчеты, статистика, документооборот, автоматический импорт товарных предложений от поставщиков и т.д. и т.п. Т.е. мы реализуем подход "все в одном", наружу - только экспорт данных для бухгалтерского учета.
Наши решения как раз и предполагают ведение клиентов и складского учета полностью в БД магазина. Аналогично там же - отчеты, статистика, документооборот, автоматический импорт товарных предложений от поставщиков и т.д. и т.п. Т.е. мы реализуем подход "все в одном", наружу - только экспорт данных для бухгалтерского учета.
Тогда если я правильно понял, логистика у Вас тоже
зашита в Вашу БД - (выписка путевок, ТТН, учет бензина, выдача денег из кассы курьерам, соответсвенно и расчет З/П, курьеров и водителей ?)
Ответить