Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

Система складского учета


serdud

Recommended Posts

Приветствую.
Есть интересная задача, решения которой я пока не нашел. Возможно, вы подскажете;)
Ситуация такова: есть розничная точка, три сотрудника и, с недавнего времени, есть интернет-магазин на опенкарт. 
Товарный ряд чуть более 500 позиций, учет ведем по-старинке в эксель. 
Товарный ряд расширяется и учет в эксель вести все сложнее. До системы 1с не доросли и это, как по мне, избыточный функционал.

Что нужно:
1. Добавлять товар на баланс
2. Списывать (продажи)
3. Перемещать (на магазин, к примеру)

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

Возможно, есть какое-то дополнение для опенкарт, чтобы на его базе решить эту задачу.
Либо подскажите какие сервисы, программы используете вы для подобного учета.
Мало верится что все освоили и используют 1с.

Заранее благодарю.

Надіслати
Поділитися на інших сайтах


1 час назад, serdud сказал:

Приветствую.
Есть интересная задача, решения которой я пока не нашел. Возможно, вы подскажете;)
Ситуация такова: есть розничная точка, три сотрудника и, с недавнего времени, есть интернет-магазин на опенкарт. 
Товарный ряд чуть более 500 позиций, учет ведем по-старинке в эксель. 
Товарный ряд расширяется и учет в эксель вести все сложнее. До системы 1с не доросли и это, как по мне, избыточный функционал.

Что нужно:
1. Добавлять товар на баланс
2. Списывать (продажи)
3. Перемещать (на магазин, к примеру)

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

Возможно, есть какое-то дополнение для опенкарт, чтобы на его базе решить эту задачу.
Либо подскажите какие сервисы, программы используете вы для подобного учета.
Мало верится что все освоили и используют 1с.

Заранее благодарю.

 

Мой склад не рассматривали?
Можно и интеграцию сделать, все будет автоматизированно.

Но тут требуется допилка руками

Змінено користувачем vyacheslav22
Надіслати
Поділитися на інших сайтах


11 часов назад, INFOBOX сказал:

Есть смысл пообщаться с разработчиками системы складского учета СКИФ. Есть опция по интеграции в опенкарт. 

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

Надіслати
Поділитися на інших сайтах

У вас своеобразное понимание слова "проблема". Никто же не тычет в висок вороненым стволом маузера, вынуждая установить им от скифа. Насколько я знаю, вы абсолютно свободны в своих действиях. Существует саппорт, который установит и настроит складской учет по указанным вами пожеланиям. Меня в Скифе привлекает расположение на собственном сервере или локально. Без каких-то  облачных сервисов и постоянной помесячной оплаты.
В качестве пробного варианта я попытался использовать систему учета ZIPPY. Моего терпения не хватило. Косяки на каджом шагу.

Надіслати
Поділитися на інших сайтах


 

33 минуты назад, INFOBOX сказал:

Меня в Скифе привлекает расположение на собственном сервере или локально. Без каких-то  облачных сервисов и постоянной помесячной оплаты.
В качестве пробного варианта я попытался использовать систему учета ZIPPY.

Для себя пока решения не нашел, zippy тоже пробовал все хорошо нет документации нормальной, и есть косяки.
1с это перебор.
Скиф не рассматривал поскольку еше давно смотрел в его сторону, а там вместе с учетом грузится движок магазина, и это уже мне не нравится. Не знаю может уже поменялось что то.
А вот Мой склад это интересно но что то у них ценник конский :(
Учитывая что задача чуть сложнее чем пару экселей.

Понятное дело что для серьезного учета нужен серьезный продукт.

А вообще тема интересная, кто чем пользуется ?
Хоть составить для себя понимания что актуально что нет. Может время появится что то рассмотреть и внедрить.

 

Надіслати
Поділитися на інших сайтах

1 минуту назад, nikifalex сказал:

Либо 1C либо пишите свое. 

Все остальное просто набраться опыта и увидеть какие глючные бывают системы с тупой поддержкой. Хотя конечно опыт тоже нужен.

То есть выше предложенное нельзя назвать вминаемым решением ?

Просто для меня 1с это как с базуки по мухе стрелять.
Эксель в 2020 уже не камельфо.

Для себя можно что то простенькое и написал бы. А так по сути есть один проект знакомых где я косвенно подсказываю и вот там нет системы учета.
То есть она есть но в экселе ))

Надіслати
Поділитися на інших сайтах

2 минуты назад, nikifalex сказал:

именно так.

а все остальные системы тоже самое, только еще ствол кривой

 

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

В этих системах есть преимущество это доступ к базе удаленно.
Я понимаю что эксель можно положить в гугл док, но это уже вообще извращение. Хоть и будет работать.

Значит как появится время нужно подумать над этим вопросом.

Надіслати
Поділитися на інших сайтах

1 hour ago, nikifalex said:

Либо 1C либо пишите свое. 

Все остальное просто набраться опыта и увидеть какие глючные бывают системы с тупой поддержкой. Хотя конечно опыт тоже нужен.

А что вы используете или чаще всего приходилось внедрять?

Надіслати
Поділитися на інших сайтах


В 04.03.2020 в 16:44, serdud сказал:

Приветствую.
Есть интересная задача, решения которой я пока не нашел. Возможно, вы подскажете;)
Ситуация такова: есть розничная точка, три сотрудника и, с недавнего времени, есть интернет-магазин на опенкарт. 
Товарный ряд чуть более 500 позиций, учет ведем по-старинке в эксель. 
Товарный ряд расширяется и учет в эксель вести все сложнее. До системы 1с не доросли и это, как по мне, избыточный функционал.

Что нужно:
1. Добавлять товар на баланс
2. Списывать (продажи)
3. Перемещать (на магазин, к примеру)

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

Возможно, есть какое-то дополнение для опенкарт, чтобы на его базе решить эту задачу.
Либо подскажите какие сервисы, программы используете вы для подобного учета.
Мало верится что все освоили и используют 1с.

Заранее благодарю.

Могу поделиться своим кейсом.

Есть магазин, товара +/- 600-700 наименований (по сути не важно, хоть 10к)

Есть магазин на опенкарт - это и есть база магазина с товаром и его физическим количеством в магазине

Есть касса со сканером штрихкода (планшет с сим картой для работы инета, такой инет не проводили + сканер и OTG переходник на сканер)

 

Задача - создать кассу и учет продаж, остатков и т.п.

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

 

Решение

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

Через ОТГ переходник к планшету подключен сканер штрих кодов и зарядка. При пиканьи сканера идет запрос в базу опенкарта где берет товар и кладет его в корзину, после того как кассир сформирует чек - идет отправка на сервер и товар списывается а заказ (со всеми данными) идет в заказы. Все это понятно отображается у кассира в планшете.

2) Сервер - сайт на опенкарт. Обычный сайт на опенкарте понятно что со своим АПИ для приема данных с кассы. В админке сайта у меня есть вся статистика, маржинальность, прибыль, приход-расход. Каждая транзакция. В общем все все данные.

 

Плюсы

1) Полный кастом - гибкость и возможность сделать все что угожно под себя. Что и было сделано. Надо добавить подсказку или ввести бонусные баллы - не проблема. Надо поиск клиента сделать - также не проблема. Поиск товара - сделано. В общем, решение делается как удобно конечному юзеру под конкретные задачи учитывая специфику работы.

2) Одна база! Без каких либо синхронизаций и прочей петрушки. есть продажа в магазине - есть она же в админке и товар на сайте 1в1 соответствует наличию товара в магазине

3) Полная информация о работе магазина с мобильного телефона. Все графики, товары, что покупают, кто, как расчитываются, даже какие купюры кладут в кассу и сколько там денег - полная информация о транзакциях и начислению ЗП. 

 

Минусы

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

 

Решение мне очень понравилось тем что это полный кастом, делаю под себя как угодно и работает отлично.

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

 

Такой кейс. Если интересуют подробности спрашивайте.

  • +1 2
Надіслати
Поділитися на інших сайтах

@Exploits Просто сходу + за подход.

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

Главное как я понял база товара это и есть база опенкарта?
Прикольно.
 

Надіслати
Поділитися на інших сайтах

1 минуту назад, Rassol2 сказал:

@Exploits Просто сходу + за подход.

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

Главное как я понял база товара это и есть база опенкарта?
Прикольно.
 

Все верно)

Надіслати
Поділитися на інших сайтах

1 минуту назад, Exploits сказал:

Все верно)

У вас наверное не было необходимости но все же.
А как решали вопрос с складами, если такой вопрос был.

Допустим есть 2-3 розничные точки. + ИМ
Ну и есть скалад который принимает товары. И затем уже раздает по розничным точкам.

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

Был вопрос с складами ? Если да то как решили его ?

Надіслати
Поділитися на інших сайтах

Со складами как такового вопроса не было из-за того что розничная точка одна.

Но если есть склад и есть точки продажи + им

Я бы сделал так

создаем в базe таблицу product_quantity c полями product_id, shop_id, quantity

и если есть склад ему даем id 100 (например)

А точкам 1,2,3 и т.п. и в базе будет примерно так

product_id shop_id quantity
345 100 300
345 1 50
345 2 10
345 3 15

В админке понятно что делаем оболочку где можно добавлять точки, редактировать количества в магазинах и все что надо и логика что quantity товара это сумма из всех точек по id товара в примере будет 375.

Но в самих магазинах я бы прописал id магазина и при продаже просто списывал бы с базы product_quantity с этой точки количество и правил это же количество в таблице product

как-то так +/-

  • +1 1
Надіслати
Поділитися на інших сайтах

1 час назад, Exploits сказал:

Со складами как такового вопроса не было из-за того что розничная точка одна.

Но если есть склад и есть точки продажи + им

Я бы сделал так

создаем в базe таблицу product_quantity c полями product_id, shop_id, quantity

и если есть склад ему даем id 100 (например)

А точкам 1,2,3 и т.п. и в базе будет примерно так

product_id shop_id quantity
345 100 300
345 1 50
345 2 10
345 3 15

В админке понятно что делаем оболочку где можно добавлять точки, редактировать количества в магазинах и все что надо и логика что quantity товара это сумма из всех точек по id товара в примере будет 375.

Но в самих магазинах я бы прописал id магазина и при продаже просто списывал бы с базы product_quantity с этой точки количество и правил это же количество в таблице product

как-то так +/-

Кстати вот есть модуль - может автор присоединится к этой интересной теме @matroskin92

 

Надіслати
Поділитися на інших сайтах

14 часов назад, Exploits сказал:

Со складами как такового вопроса не было из-за того что розничная точка одна.

Но если есть склад и есть точки продажи + им

Я бы сделал так

создаем в базe таблицу product_quantity c полями product_id, shop_id, quantity

и если есть склад ему даем id 100 (например)

А точкам 1,2,3 и т.п. и в базе будет примерно так

product_id shop_id quantity
345 100 300
345 1 50
345 2 10
345 3 15

В админке понятно что делаем оболочку где можно добавлять точки, редактировать количества в магазинах и все что надо и логика что quantity товара это сумма из всех точек по id товара в примере будет 375.

Но в самих магазинах я бы прописал id магазина и при продаже просто списывал бы с базы product_quantity с этой точки количество и правил это же количество в таблице product

как-то так +/-

При таком раскладе можно использовать разные магазины как разные склады )
 

Спойлер

80F3HrM.png

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

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

Надіслати
Поділитися на інших сайтах

6 часов назад, nikifalex сказал:

я видел модуль с таким извращением, где в product_to_store добавили колонки price, quantity и еще какие-то.

 

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

да про количество в опциях я как то сразу и не подумал.
Для учете такой подход это конечно проблема.

Надіслати
Поділитися на інших сайтах

поэтому и не только вместо опций лучше делать товарами и связывать вот таким )
именно всё эти нюансы с никчёмными и урезанными опциями и явились толчком для создания этого и иного модуля

 

 

По теме я бы сделал так.
доп склады по id товара. (там же уже при заказе понятно откуда отнимать кол-во при обработке заказа.
Пример три поля (хоч ещё создал\удалил)
общее кол-во одного товара на складах ровняем в стандарте ок в общем кол-ве товара .
всё
и лучше в ок всё организовывать и отсылать в 1С а не "по геморойному" на оборот

Надіслати
Поділитися на інших сайтах


1 минуту назад, AWARO сказал:

поэтому и не только вместо опций лучше делать товарами и связывать вот таким )

Оп, и маркет плейс подъехал )

Надіслати
Поділитися на інших сайтах

3 минуты назад, Rassol2 сказал:

Оп, и маркет плейс подъехал )

можно и индивидуально) если не жалко  бабла ))

Надіслати
Поділитися на інших сайтах


11 минут назад, AWARO сказал:

По теме я бы сделал так.
доп склады по id товара. (там же уже при заказе понятно откуда отнимать кол-во при обработке заказа.
Пример три поля (хоч ещё создал\удалил)
общее кол-во одного товара на складах ровняем в стандарте ок в общем кол-ве товара .
всё
и лучше в ок всё организовывать и отсылать в 1С а не на геморойный на оборот

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

А по сути это то что нужно, осталось только время выделить под это.
По сути это то что меня и интересовало в этой теме.
 

  • +1 1
Надіслати
Поділитися на інших сайтах

20 минут назад, Rassol2 сказал:

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

А по сути это то что нужно, осталось только время выделить под это.
По сути это то что меня и интересовало в этой теме.
 

У меня очень приочень дофига таких то что нужно))
проблема в том что 98% кодеров или ахеревшие (я властилин всея мира а все остальные пеньки), алканафты, лентяи и драндулеты ))
а я ваще ноль во всём этом, нифига не умею иначе бы высыпал всю давно на площадку.


 

Надіслати
Поділитися на інших сайтах


В 07.03.2020 в 19:19, AWARO сказал:

У меня очень приочень дофига таких то что нужно))
проблема в том что 98% кодеров или ахеревшие (я властилин всея мира а все остальные пеньки), алканафты, лентяи и драндулеты ))
а я ваще ноль во всём этом, нифига не умею иначе бы высыпал всю давно на площадку.

Ну а у меня реально времени мало, поскольку нужно свой модуль догнать по функционалу который будет соответствовать 2020.
А потом можно и подумать о складском учете :)

Надіслати
Поділитися на інших сайтах

В 11.03.2020 в 19:25, Rassol2 сказал:

Ну а у меня реально времени мало, поскольку нужно свой модуль догнать по функционалу который будет соответствовать 2020.
А потом можно и подумать о складском учете :)

там ещё 2021 и т.д. )

Надіслати
Поділитися на інших сайтах


Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.