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