Выбор между 1С и Navision

[artkashin]

Цитата:

Сообщение от abs

Navision в своей базовой конфигурации позволит "задать" следующие процессы:

1. Заказ товара по следующей схеме:
Есть центральный офис, есть торговые точки и есть центральный склад (распределительный центр).
Менеджеры по закупкам работают в центральном офисе и, на основании каких-то отчетов, формируют заказ поставщикам.
Товар поступает на центральный склад.
Менеджеры на торговых точках формируют свои заказы, в соответствии с продажами на своих точках, на центральный склад.

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

Подобную схему можно реализовать, но дело в другом: система базируюется на алгоритме MRP-II
http://axapta.mazzy.ru/lib/mrp/
и призвана нести этот стандарт в массы и, соответственно, максимально эффективно работает тогда, когда на практике он используется. (В пресс-релизах некоторых компаний встречаются такие строчки:благодаря внедрению системы удалось уменьшить отдел закупок с 6 человек до 1, и соответствующая выгода от экономии зарплаты). Поэтому, если вы не готовы работать по MRP-II значит под вас (возможно, так как функционал в этой области достаточно богат) потребуется доделки-дописки этих самых "механизмов" облегчающих жизнь этим 6 менеджерам.

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

Цитата:

Сообщение от abs

2. "Быстрые" продажи по следующим схемам:
а) розница (фискальный регистратор, сканеры штрих-кода) + отпуск в кредит
б) розница (фискальный регистратор, сканеры штрих-кода) + отпуск в кредит + отпуск юр. лицам (в розницу - на отдельном фискальном регистраторе и по безналичному расчету /включая работу по договорам/)

Стандарт Nava, как POS-система, слаб. Существуют специализированные решения для розничной торговли, но за отдельную плату. (Дописывать связь с фискальным регистратором, сканеры штрих-кода (стандартный ACDS никто не использует, покрайней мере не слышал об этом) Если же просто необходим учет розничных продаж, то это, конечно возможно.
Про отпуск в кредит можно по подробнее? насколько я понимаю, компания получает полностью деньги за товар, только с кредитного банковского счета клиента, по безналу? Тогда это легко настраивается стандартными средствами.

Цитата:

Сообщение от abs

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

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

Цитата:

Сообщение от abs

4. Управление персоналом. Контроль и оценка работы всех отделов (отдел закупок, отдел маргетинга, показатели работы торговых точек, бухгалтерии и т.п.), учет всех расходов по компании, начисление з/платы сотрудникам, планирование финансов и распределение прибыли.
Есть ли это в Navision ? Или что-то из перечисленного в типовой конфигурации отсутствует ?

Оценки работы отделов как критерия - нет. Естественно, можно получить множество поямых (продажи за месяц по точкам) и косвенных показателей (Количество несвоевременно отгруженных заказов). Стандартно зарплата есть. Вопрос только в том, что для целей Российского Бухучета она не подходит определенно, если не совсем простая. Проще расчитать где-то, а в систему кидать финансовыми суммами. Все остальное - стандарт. Естественно, у каждого внедренца есть свои наработки в каких-то из областей. Ну и в "Типовой конфигурации" отсутствуют какие-то ни было бухгалтерские формы РСБУ, включая ТОРГ-12 и СЧЕТ-ФАКТУРУ.

[abs]

Цитата:

Сообщение от Kashin

Подобную схему можно реализовать, но дело в другом: система базируюется на алгоритме MRP-II
http://axapta.mazzy.ru/lib/mrp/
и призвана нести этот стандарт в массы и, соответственно, максимально эффективно работает тогда, когда на практике он используется.

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

Возможно Вы имели ввиду другое - саму схему работы с заказами ? Т.е. централизованные заказы и децентрализованные, как в АСТОР Торговая сеть: либо заказ поступает с точек реализации, в центре все заказы объединяются и пересылаются поставщикам (т.е. каждая точка работает "сама по себе"), либо заказ целиком формируют в центре и, после его "исполнения", товар попадает через распределительный центр на торговые точки ?
У нас получается смешанный тип заказа (не совсем централизованный и не совсем разделенный). Т.е. заказ поставщикам делает один отдел, основываясь на информации со всех торговых точек. А торговые точки заказывают товар только с распределительного центра в рамках своего ассортимента.
Если так, то что нам надо изменить в своем процессе заказа, чтобы "вписаться" в типовое решение Axapta или Navision ?

Цитата:

Сообщение от Kashin

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

А работа с ассортиментом как реализована ? Т.е. есть ли понятие ассортиментных матриц ? Или какой-либо другой механиз управления и контроля ассортимента торговых точек и всей компании в целом ?

Цитата:

Сообщение от Kashin

Стандарт Nava, как POS-система, слаб. Существуют специализированные решения для розничной торговли, но за отдельную плату. (Дописывать связь с фискальным регистратором, сканеры штрих-кода (стандартный ACDS никто не использует, покрайней мере не слышал об этом) Если же просто необходим учет розничных продаж, то это, конечно возможно.

Т.е., наверно, если задаваться целью делать как можно меньше доработок в типовых версиях Axapta и Navision, то выход из данной проблемы с POS и сканерами штрихов - это осуществление продаж в отдельной кассовой программе с дальнейшим "перегоном" продаж в систему - Axapta или Navision ? Или отход от сканеров и активных касс - продавцы работают в Axapta или Navision и розничные чеки пробивают "в ручную" ?

Цитата:

Сообщение от Kashin

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

Именно такая схема. Только еще есть один нюанс, связанный с тем, что по некоторым видам кредита (акциям, как их называет банк), сам банк платит некоему лицу агентское вознагрождение по каждому кредиту. Официально это лицо является сторонним для Компании, но реально, это и есть сама Компания (управляющий или учредитель). Т.е. автоматический учет такой ситуации возможен в типовых версиях ?
Также кредиты могут быть оформлены по разным кредитным программам, соответсвенно желательно видеть в системе настройку под разные виды кредита (с первоначальным взносом, без первоначального взноса, с банковской коммисией). Т.к. в конечном итоге это выливается в бухгалтерский и управленческий учет кредитных операций.

Цитата:

Сообщение от Kashin

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

Понял, тут нужно уже прояснять вопрос непосредственно с теми, кто будет внедрять.

Цитата:

Сообщение от Kashin

Стандартно зарплата есть. Вопрос только в том, что для целей Российского Бухучета она не подходит определенно, если не совсем простая. Проще расчитать где-то, а в систему кидать финансовыми суммами. Все остальное - стандарт. Естественно, у каждого внедренца есть свои наработки в каких-то из областей. Ну и в "Типовой конфигурации" отсутствуют какие-то ни было бухгалтерские формы РСБУ, включая ТОРГ-12 и СЧЕТ-ФАКТУРУ.

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

[RedFox]

Цитата:

Сообщение от abs

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

Возможно Вы имели ввиду другое - саму схему работы с заказами ? Т.е. централизованные заказы и децентрализованные, как в АСТОР Торговая сеть: либо заказ поступает с точек реализации, в центре все заказы объединяются и пересылаются поставщикам (т.е. каждая точка работает "сама по себе"), либо заказ целиком формируют в центре и, после его "исполнения", товар попадает через распределительный центр на торговые точки ?
У нас получается смешанный тип заказа (не совсем централизованный и не совсем разделенный). Т.е. заказ поставщикам делает один отдел, основываясь на информации со всех торговых точек. А торговые точки заказывают товар только с распределительного центра в рамках своего ассортимента.
Если так, то что нам надо изменить в своем процессе заказа, чтобы "вписаться" в типовое решение Axapta или Navision ?

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

Цитата:

А работа с ассортиментом как реализована ? Т.е. есть ли понятие ассортиментных матриц ? Или какой-либо другой механиз управления и контроля ассортимента торговых точек и всей компании в целом ?
Т.е., наверно, если задаваться целью делать как можно меньше доработок в типовых версиях Axapta и Navision, то выход из данной проблемы с POS и сканерами штрихов - это осуществление продаж в отдельной кассовой программе с дальнейшим "перегоном" продаж в систему - Axapta или Navision ? Или отход от сканеров и активных касс - продавцы работают в Axapta или Navision и розничные чеки пробивают "в ручную" ?

Ассортиментные матрицы наверное Вам лучше доделать простой формой на товарах, SKU, вариантах и поставщиках на основе продаж (предполагаю, что расчитывать данные Вы будете по своему), а вот работа со штрих-кодами вроде неплохо работает в NAV как перекресная ссылка (штрих-код, Клиент, Поставщик) без всяких доработок. И не надо отказываться ни от чего, а просто доделать работу с драйверами фискального регистратора в стандартном функционале.

Цитата:

Именно такая схема. Только еще есть один нюанс, связанный с тем, что по некоторым видам кредита (акциям, как их называет банк), сам банк платит некоему лицу агентское вознагрождение по каждому кредиту. Официально это лицо является сторонним для Компании, но реально, это и есть сама Компания (управляющий или учредитель). Т.е. автоматический учет такой ситуации возможен в типовых версиях ?
Также кредиты могут быть оформлены по разным кредитным программам, соответсвенно желательно видеть в системе настройку под разные виды кредита (с первоначальным взносом, без первоначального взноса, с банковской коммисией). Т.к. в конечном итоге это выливается в бухгалтерский и управленческий учет кредитных операций.

Как писали выше процент-ноты с небольшой доработкой (возможность выставить ее другому лицу по какому-то признаку или "указанию").

[artkashin]

Цитата:

Сообщение от abs

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

Возможно Вы имели ввиду другое - саму схему работы с заказами ? Т.е. централизованные заказы и децентрализованные, как в АСТОР Торговая сеть: либо заказ поступает с точек реализации, в центре все заказы объединяются и пересылаются поставщикам (т.е. каждая точка работает "сама по себе"), либо заказ целиком формируют в центре и, после его "исполнения", товар попадает через распределительный центр на торговые точки ?
У нас получается смешанный тип заказа (не совсем централизованный и не совсем разделенный). Т.е. заказ поставщикам делает один отдел, основываясь на информации со всех торговых точек. А торговые точки заказывают товар только с распределительного центра в рамках своего ассортимента.
Если так, то что нам надо изменить в своем процессе заказа, чтобы "вписаться" в типовое решение Axapta или Navision ?

Если вы не хотите менять процессы заказа товаров - менять и не прийдется. Я лишь написал об максимальной эффективности.

Цитата:

Сообщение от abs

А работа с ассортиментом как реализована ? Т.е. есть ли понятие ассортиментных матриц ? Или какой-либо другой механиз управления и контроля ассортимента торговых точек и всей компании в целом ?

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

Цитата:

Сообщение от abs

Т.е., наверно, если задаваться целью делать как можно меньше доработок в типовых версиях Axapta и Navision, то выход из данной проблемы с POS и сканерами штрихов - это осуществление продаж в отдельной кассовой программе с дальнейшим "перегоном" продаж в систему - Axapta или Navision ? Или отход от сканеров и активных касс - продавцы работают в Axapta или Navision и розничные чеки пробивают "в ручную" ?

тут сложный вопрос. Дело в том, что специализированные кассовые терминалы, на то они и специализированные. Т.е. использование такого заточенного терминала решает большинство розничных проблем в коробочной версии. Да, существуют доработки на базе Navision (LS Retail). Я не могу судить об их качестве, СТОИМОСТИ и эффективности, так как никогда их не видел. В любом случае это отдельный ADD-ON. Доработки стандартной базы под нужды розницы - дело, на мой взгляд, не благодарное, так как необходимо реализовывать множество специфичных розничных требований самостоятельно, используя труд программиста, а это значит отлов багов, отдельный специалист на поддержку розничного решения. Тем более, что часто внедренцы предлагают к внедрению одну централизованную базу для всего предприятия, а в этом случае розничное решение вызывает еще больше вопросов.

Цитата:

Сообщение от abs

Именно такая схема. Только еще есть один нюанс, связанный с тем, что по некоторым видам кредита (акциям, как их называет банк), сам банк платит некоему лицу агентское вознагрождение по каждому кредиту. Официально это лицо является сторонним для Компании, но реально, это и есть сама Компания (управляющий или учредитель). Т.е. автоматический учет такой ситуации возможен в типовых версиях ?

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

Дорабатывать систему.

Цитата:

Сообщение от abs

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

нет, стандартно нет. Спрашивайте у внедренца.

Цитата:

Сообщение от Галина

Поправлю Kashin. Торг12 и счет фактура есть.

Да, точно есть :-)

[RedFox]

Цитата:

Сообщение от Kashin

тут сложный вопрос. Дело в том, что специализированные кассовые терминалы, на то они и специализированные. Т.е. использование такого заточенного терминала решает большинство розничных проблем в коробочной версии. Да, существуют доработки на базе Navision (LS Retail). Я не могу судить об их качестве, СТОИМОСТИ и эффективности, так как никогда их не видел. В любом случае это отдельный ADD-ON. Доработки стандартной базы под нужды розницы - дело, на мой взгляд, не благодарное, так как необходимо реализовывать множество специфичных розничных требований самостоятельно, используя труд программиста, а это значит отлов багов, отдельный специалист на поддержку розничного решения. Тем более, что часто внедренцы предлагают к внедрению одну централизованную базу для всего предприятия, а в этом случае розничное решение вызывает еще больше вопросов.

Ну почему все считают, что если розница (любая, в том числе и магазины мобилок, чехлов, книг и т.д.), то сразу нужен POS-терминал, куча примочек к нему и т.д. Я просто иногда устаю говорить, что это не всегда так...
Стандарный Заказ Продажи поддерживает сканеры в разрыв клавиатуры (я специально не условжняю по оборудованию, чтобы уменьшить сложность), и штрих-коды, и серийные номера, гарантийные талоны, принтеры (доработать слегка и фискальные тоже) и т.д. ....
Ну не надо сразу все усложнять. Просто для начала определиться что нужно ;-)

[RedFox]

Цитата:

Сообщение от Kashin

Стандарт Nava, как POS-система, слаб. Существуют специализированные решения для розничной торговли, но за отдельную плату. (Дописывать связь с фискальным регистратором, сканеры штрих-кода (стандартный ACDS никто не использует, покрайней мере не слышал об этом) Если же просто необходим учет розничных продаж, то это, конечно возможно.

Можно просто слегка доделать стандартную форму и дописать работу (печать чеков, гарантий и т.д.) с фискальным регистратором (а не пользоваться специальной POS-системой, которая кстати, есть Add-On к NAV c полным функциональным набором!!). для компьютерной розницы 98% подходит без всяких там дополнительныз решений (включая серийники, сроки гарантии и прочее)...
ACDS преднаначена в основном для работы на складах, ну не как ни в магазинах!!!

Цитата:

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

И продажа в кредит, с отсрочкой и т.д. можно сделать без проблем (если нет особенных требований)..
Ну а ценообразование вполне нормальное. А вот требования клиента в каждом случае свои (как и работа ценообразование в его бизнес-модели). с Add-On LS-Retail больше практически ничего не нужно. Даже подарочные сертификаты и купоны с бонусами есть.

Вобщем решать заказчику. Но нужно понимать, что система НЕ БУДЕТ ГЛОБАЛЬНОЙ ПАНАЦЕЕЙ и РЕШЕНИЕМ НА ВСЕ СЛУЧАИ ЖИЗНИ!!! Самое главное - ВОВРЕМЯ ОСТАНОВИТЬ ХОТЕНИЕ и не потерять линию что должна делать система и что должен делать человек. Поэтому без дополнительных программ любая система (в том числе Oracle) не сделает Вам анализ работы подразделения (или имелось ввиду групы товаров?)!!! Поэтому для товарного анализа формочка анализа продаж, либо анализ по Измерениям. Либо вообще совместно с SQL и Analizer строить аналитические кубы и анализировать как душе угодно.