Цитата:
Изначально опубликовано xonix
2 Alks
Цитата:
Задача сопряжения в данном случае не сложная. Не буду углубляться в детали, вкратце - в одну сторону идут справочники (и только они), в другую - факты (неизменные, т.е. не надо поддерживать UPDATE ).
Не соглашусь в том, что мы здесь помимо чисто технических проблем переноса данных (решабельных конечно) можем столкнуться с идеологическими различиями в системах кассового сервера (КС) и аксапты. Например - уже видно что КС (несомненно классный, но сторонее решение почти никогда не будет идеальным для конкретного заказчика) не поддерживает номенклатурные аналитики, а мы используем одну. Придется вводить аналитику как часть артикула, что уже уродливо, но с пивом покатит. Уже видно что будет трудно увязать прайс листы КС и аксапты. И это при всё при том, что мы КС еще в глаза не видели - привезти и показать её нам в первый раз должны были сегодня кстати.
Цитата:
Весь вопрос в том, что в описанном случае такую работу (разработку) предстоит выполнять внешним программерам по 60-80 долл/час. С учётом проектирования, прототипирования, разработки, полного тестирования недёшево получится.
Когда я говорил что в случае если купленный кассовый сервер нам не понравится и тогда МЫ вероятнее всего сделаем его на аксапте, под словом МЫ я имел ввиду именно НАС, а не сторонних разработчиков. А зарплата у нас умеренная.
Цитата:
2. Справочники.
Вы тогда определитесь.. Вот товарисч говорит, что ему "дерево" для аналитики надо.
Вы разницу между задачей быстрого поиска в классификаторе, и аналитики поверх дерева чувствуете?
И согласен и не согласен одновременно.
"Быстрый поиск" - это ведь по существу, если разобраться задача "аналитики-на-лету". Другими словами уровень аналитики в отчёте здесь требуется именно такой же как и на уровне фильтрации и поиска - ничего страшного если смешать эти вещи в одну кучу не случится. Даже наоборот - сэкономим место в мозгах.
Цитата:
Для поиска можно продумать классификацию товаров, где 2-х буквенные аббревиатуры определяют уровень дерева. Ой.. вам уже указали на ветки, где это обсуждалось.
1. У такого подхода возможны "ложные" срабатывания, которые там же обсуждались
2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей
3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.:
4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто)
5. Мне лично показалось что в той ветке в конечном итоге сторонники древовидных классификаторов привели достаточно веские аргументы
Цитата:
Как руководство отчёты характеризует - то это им видней, конечно. Уверен, что и отчёты вашего руководства в другой компании тоже могут назвать "никакущими".
Да конечно. Тут наверное вся проблема в том что руководство наше (как и мы впрочем) "выросло" в 1С и решительно не понимает, почему то что так хорошо, просто, доступно, удобно и естественно работало там не может так же хорошо, просто, удобно и естественно работать здесь. =8() А это действительно большой вопрос.
Цитата:
А как программиста я вас понимаю...
Все люди - братья.