[ОТВЕТИТЬ]
05.05.2010 18:06
Назым
 
Цитата:
анюта хочу перевести магазин с 1С на супермаг, возникает вопрос - в магазине около 10000 наименований товара, как перенести в Супермаг эти данные?
В свое время решал такую задачу. Я сделал выгрузку из 1С. Олег сделал загрузку в Супермаг, за вознаграждение
05.05.2010 22:03
Dim
 
Цитата:
анюта хочу перевести магазин с 1С на супермаг, возникает вопрос - в магазине около 10000 наименований товара, как перенести в Супермаг эти данные?
версия СМ? в последних версиях в сетевом варианте есть загрузка карточек из Excel
05.05.2010 22:12
анюта
 
пока еще ничего не обговаривалось, и, к сожалению, я не специалист в этой области. Магазин одиночный, с производством, базы готовой нет, просто хотелось бы понять насколько это проблематично
05.05.2010 23:12
Dim
 
вообще всегда рекомендуют номенклатуру вбивать руками, чтобы не переносить бардак из старой программы...
23.07.2010 07:38
HollyWooD
 
Добрый день.
Встал вопрос о переходе с Домино 7.4, на 1С 8.2
Порядка 40 тысяч карточек, очень большой магазин. Супермаг так же заинтересовал.
Собственно вопрос следующий; Стоит-ли слезать с Домино, и какие могут быть предложения? Размер базы Домино 7гб, 1С 7гб. Хотим все в кучу, а то вроде 21 век, а мы выгрузки ежедневно делаем туда-сюда.
Спасибо.
23.07.2010 08:28
Mtirt
 
Выгрузки не зло, насколько я понимаю.
Вопрос в другом.
Чего не хватает в Домино, из того, что вам нужно для жизни?
Маркетинга, лояльности покупателей, учета или чего-то еще?
23.07.2010 08:49
HollyWooD
 
Цитата:
Mtirt Выгрузки не зло, насколько я понимаю.
Вопрос в другом.
Чего не хватает в Домино, из того, что вам нужно для жизни?
Маркетинга, лояльности покупателей, учета или чего-то еще?
Я не верно выразился, скорее это некая фишка Домино. :)
Я просто опишу минусы Домино 7.4
1. Загрузки кассовых лент, каждая около 7-10 минут.
2. Оборотка, каждый день порядка 3-4 часов, бывает и более
3. Отчеты, абсолютно нулевые
4. Бывает приходится поломать голову, после загрузок с 1С
5. Копеечки правятся от 1 до 5 часов, в зависимости от их количества.
6. Ну и конечно же у меня нет желания изучать Домино.
Домино может и сильная система, но слишком умная.
Стоит цель примерно такая: Засунуть все что есть в 1 кучу..., и директор склоняется к такому-же выводу.
23.07.2010 08:53
Mtirt
 
Хорошо, тогда второй вопрос.
Какое железо есть.
Кассы, весы, сканеры штрих-кода, терминалы сбора данных и т.д.
Потому как и Супермаг и 1С сложно заставить работать с неспецифичным для них железом...
23.07.2010 09:08
HollyWooD
 
Цитата:
Mtirt Хорошо, тогда второй вопрос.
Какое железо есть.
Кассы, весы, сканеры штрих-кода, терминалы сбора данных и т.д.
Потому как и Супермаг и 1С сложно заставить работать с неспецифичным для них железом...
Железо под сервер есть, если не хватит думаю купим новый.
На кассах стоит нечто странное, проще говоря там профит и если будет 1С, то убирать его не намерены, банальные txt думаю подхватит без проблем. Как обстоят дела с СМ не представляю, но видел что требуется 200 mhz с этим проблем так-же нет. Фискальники: posprint fp410k. Весы исключительно МТ-3600. Сканеры 100 процентов работают с 1С, модель увы не помню.
27.07.2010 12:33
gslxxx
 
HollyWooD, добрый день, насколько я пониаю, Вы общались с нашим коммерческим директором (РКС сервис Сибирь) по поводу поддержки имеющегося у вас оборудования Супермагом, мы дополнительно уточнили у разработчика (сервисплюс) - они говорят, что под такой проект без проблем сделают поддержку ваших фискальников за 1 месяц (нужна только документация на них и сам фискальник) и можно будет установить полноценную торговую систему - Супермаг2000 на бэкофис и УКМ4 на кассы, по опыту - это гораздо стабильнее и удобнее в администрировании чем 1С с чем бы то нибыло :)
29.03.2011 12:23
wil0909
 
Уважаемые коллеги!
Мы таки имеем что спросить.

Супермаг 1.028 Перевод работающего магазина
Описание
Карточки забили с нуля в ЦО
Проставили контракты с поставщиками.
Цены розничные установили на основании контрактов.
На 2000 карточек, которые не успели установить контракты проставили розничные цены из старой программы.
Сняли остатки товаров через ТСД в акт обнаружений.
Запустили магазин.

Руководство дает ТЗ:
Цели
1. Взаиморасчеты с поставщиками
Перенос остатков с привязкой к поставщикам для определения сроков оплаты за поставленный товар
2. Определение себестоимости товара на остатках

Решение
На основании исходных данных, предоставленных старой программой , в БД Супермаг будут созданы накладные на приход по датам накладных от поставщиков, по товарам в количестве реальном, находящимся на остатках, и ценам по накладным.

Входной массив данных имеет следующую структуру:
Сканкод
используется для идентификации товара при формировании позиции прихода
Приходная цена
данные помещаются в поле «приходная цена» формируемого документа приходная накладная
Остаток
данные помещаются в поле «количество» формируемого документа приходная накладная
Дата приходной накладной
помещается в поле дата приходной накладной

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

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

В БД Супермаг данные будут импотрированы скриптами в следующие таблицы: SmDocuments, SmWaybillsIn, SMSpec.

Вопрос.
Правильно ли мы поступаем с импортом или нет, если нет то почему?
Наколько безопасно создавать документы (пусть хотя бы и черновики) напрямую в БД не используя штатные процедуры.
29.03.2011 12:33
Mtirt
 
Про отрицательные остатки не забудьте...
Их тоже надо переносить, если они есть.

И в чем трудность с весовыми товарами и внутренними штрих-кодами?
Добавьте в карточку имеющийся в старой программе штрих-код, как внешний.
29.03.2011 12:36
Dim
 
а почему бы из старой программы не сделать выгрузку в формате, который понимается супермагом? и закачать нормально в накладные?
29.03.2011 12:39
Mtirt
 
Цитата:
Dim а почему бы из старой программы не сделать выгрузку в формате, который понимается супермагом? и закачать нормально в накладные?
А какой формат понимается Супермагом?
Ты про почтовый модуль и XML?
А если одиночный магазин?
29.03.2011 12:58
akonev
 
налогообложение? возможно, SMSPECTAX надо еще зацепить
29.03.2011 14:29
Dim
 
Цитата:
Mtirt А какой формат понимается Супермагом?
Ты про почтовый модуль и XML?
А если одиночный магазин?
нет... я про эмуляцию ТСД. такми образом переносил остатки по 5 магазинам, переходящим с астора на СМ
29.03.2011 14:35
Mtirt
 
А цены разве там есть?
29.03.2011 14:39
Dim
 
выгружаю цены закупа и розницы (есть в ФАКе), загружаю в акты переоценки, остатки загружаю в приходную или в сличилку...
29.03.2011 15:24
bob
 
Цитата:
Dim выгружаю цены закупа и розницы (есть в ФАКе), загружаю в акты переоценки, остатки загружаю в приходную или в сличилку...
Остатки полученные таким образом их не устраивают (см. первый пост). Поэтому единственно правильное (на мой взгляд) решение - тащить все скриптами, как они и написали в черновики, а потом принимать их до зеленой галки. Про засады данного метода не в курсе. не делали. Но если бы стояла такая задача, то в первую очередь эксперементировали бы с этим вариантом.
29.03.2011 20:55
YuraZ
 
Мне кажется, что если задача стоит столь глобальная с детальной проработкой, то использование XML конвертора будет наиболее оптимальным вариантом. В этом случае Супермаг сам будет создавать документы с необходимыми проверками. С точки зрения "правильности" этот вариант наиболее правильный и защищающий от ситуаций, когда чего то не учли при написании скриптов.
Если речь идет о одиночном магазине, то никто не мешает поставить на него почтовый модуль и получить временную полную лицензию.
29.03.2011 20:57
Dim
 
Цитата:
bob Остатки полученные таким образом их не устраивают (см. первый пост). Поэтому единственно правильное (на мой взгляд) решение - тащить все скриптами, как они и написали в черновики, а потом принимать их до зеленой галки. Про засады данного метода не в курсе. не делали. Но если бы стояла такая задача, то в первую очередь эксперементировали бы с этим вариантом.
опять-таки... если бы была 1С я бы выгружал бы остатки по каждой поставке...
29.03.2011 21:27
baggio
 
Цитата:
Dim опять-таки... если бы была 1С я бы выгружал бы остатки по каждой поставке...
согласен с димом... потрачено на скрипты будет много времени... а толку мало, точнее не больше, косяков может вылезти туча при незнании структуры БД и т.д. ... выгрузить из 1с остатки по Каждому из поставщиков в отдельный файл и загрузить их в СМ ... по разным накладным... быстрее проще нагляднее.. имхо..
29.03.2011 21:32
bob
 
Цитата:
Dim опять-таки... если бы была 1С я бы выгружал бы остатки по каждой поставке...
Угу. а притягивать цены по партиям из актов переоценки (которые еще надо создать) занятие малоприятное. Проходили. Причем поставщиков было немного. А если их много и много партий - то геморрой обеспечен.
29.03.2011 21:43
Dim
 
не понял... есть данные по остаткам из разных поставок. почему нельзя вытащить по каждой партии закупочную цену? и одним АП потом поставить продажную?
29.03.2011 22:23
bob
 
Цитата:
Dim не понял... есть данные по остаткам из разных поставок. почему нельзя вытащить по каждой партии закупочную цену? и одним АП потом поставить продажную?
Прокрути ситуацию с 200 поставщивами и 1000 а то и больше партий на всех поставщиков. причем у партий товара разные закупочные цены. Тебе понадобится создать на каждую партию свой акт переоценки, притягивать цены из этого акта переоценки, не говоря уже о том что просто из черновика их в конкретную накладную средствами СМ не притянуть.
30.03.2011 07:58
akonev
 
Цитата:
bob ...Тебе понадобится создать на каждую партию свой акт переоценки...
Это зачем? Вопрос розничных цен вообще не стоит. Выставили они уже розницу.
На кой ляд тянуть закупочные цены партий в акты переоценок, если они нужны в приходах?
30.03.2011 08:08
Mtirt
 
Цитата:
Andrew_Konev Это зачем? Вопрос розничных цен вообще не стоит. Выставили они уже розницу.
На кой ляд тянуть закупочные цены партий в акты переоценок, если они нужны в приходах?
В приходы то их тоже надо как-то затолкать.
Например из актов переоценок с типом цены "Закупочная".
Но все равно не пойдут суммовые остатки по себестоимости.
В старой программе было 3 шт по 10 руб и 5 шт по 12 руб.
Даже имея акты, сложно будет проставить без вмешательства вручную правильные закупочные цены.

Так что, лично я за XML
30.03.2011 08:16
bob
 
Цитата:
wil0909 Уважаемые коллеги!
Мы таки имеем что спросить.

Вопрос.
Правильно ли мы поступаем с импортом или нет, если нет то почему?
Наколько безопасно создавать документы (пусть хотя бы и черновики) напрямую в БД не используя штатные процедуры.
Ничего страшного нет. Мы именно так и поступили в одном из случаев.
про XML ничего не скажу, потому что не пользовался.
30.03.2011 08:35
akonev
 
Цитата:
Mtirt ...Так что, лично я за XML
я, собственно, тоже.

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

если же навыка записи в базу нет и все равно надо разбираться - то, имхо, лучше для начала разбираться с XML.
30.03.2011 09:48
Dim
 
1. выгружаем остатки по каждому приходу в отдельный файл, цены (закуп и продажа) тоже в отдельные файлы.
2. Берем по порядку файлы по каждой накладной и эмуляцией портативного терминала загружаем в СМ (колво в приходную, цены в акты переоценки)
3. Приход заполняем закупочными ценами, принимаем.

в итоге имеем остатки по каждой накладной с "правильными" закупочными ценами. розничные цены можно вытянуть одним файлом и прогрузить в один акт переоценки.


Опции темы


Часовой пояс GMT +3, время: 14:57.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.