Можно ли верить разработчикам?

[Клиент]

Приветствую

Вопрос в следующем.
Требуется поставить в розничный магазин Аксапту.
Я только ставлю ТЗ фирме, внедряющей Аксапту у нас.
Разработчики этой фирмы утверждают, что в полном объеме
это невозможно. Т.е.:
-Аксапта не умеет работать с подключенным
по Com-порту фискальным регистратором.
-В Аксапте нельзя реализовать вложенные справочники.
/иерархические справочники/
Например, хотя бы всего два уровня: Клиенты - их торговые точки.

Мне очень нужен Ваш совет, Ваше мнение.
Т.к. я сам систему знаю слишком поверхностно
и не могу аргументировать.
Но почему-то нашим разработчикам не верится.
Может я не прав, и надо больше доверять людям?

[bucken]

Сугубо мое мнение:
1) Сделать можно ВСЕ.
Но, есть ограничения: время, квалификация, деньги, качество и т.д
Т.е. например можно и на Ассемблере всю Аксапта переписать. Но скольо это займет по времени и сколько это будет стоить?

2) По поводу работы с Фискальными регистраторами - конкретно такого не видел. Но тут(форуме) по всюду видно, что народ сопрягал(УСПЕШНО) сканер штих кодов с Аксаптой. Т.е. это возможно.

3) По поводу иерархический справочников - это тоже можно. Тема на форуме Абстрактный классификатор из ряда аналогичных тем.

Замечания:

1) То о чем вы спросили - по большей части технические аспекты. Возможность реализации ваших требований зависит по большей части от того ЧТО вы(Ваши БИЗНЕС ПРОЦЕССЫ) хотят от работы с фискальными регистраторами и зачем нужен спец. справочник. Понятное дело, что они вам нужны. Вопрос в том ЧТО (отчет, алгоритм) вам нужно в ДЕТАЛЯХ.
2) По поводу разработчиков - это ведь далеко не люди с лопатой, просто наверняка есть какие-то "детали" не возможности реализации. Они вам просто так НЕЛЬЗЯ не могли сказать. Опять же таки дъявол в "деталях". Ничего ли вы не упустили из их утверждений?

[bucken]

И еще одно:
На рынке существуют решения для розничной торговли. КОРСИ пойму такое предлагает, но могу ошибаться. Может стоить купить решение и заточить под вашу розницу? Сделать субподряд.

[Alexandre]

Цитата:

Изначально опубликовано Клиент
Приветствую

Вопрос в следующем.
Требуется поставить в розничный магазин Аксапту.
Я только ставлю ТЗ фирме, внедряющей Аксапту у нас.
Разработчики этой фирмы утверждают, что в полном объеме
это невозможно. Т.е.:
-Аксапта не умеет работать с подключенным
по Com-порту фискальным регистратором.
-В Аксапте нельзя реализовать вложенные справочники.
/иерархические справочники/
Например, хотя бы всего два уровня: Клиенты - их торговые точки.
Может я не прав, и надо больше доверять людям?

Обманывают, т.к. люди ленивы по своей сути.
Мы реализовывали в своих проектах и иерархические справочники и связь по Com портам. Хоть с Axapta, хоть с Navision.
Вы в online хотите пробивки фискального регистратора видеть в Аксапта ввиде проводок?
Хочу предостеречь от этого!

[xonix]

Не пинать ногами, но:
Не надо прикручивать к аксапте фискальный регистратор.
Ставьте на кассу простенькую прогу, которая позволяет делать продажи, а в Аксапту сбрасывайте ежедневный консолидированный отчёт о продажах.
Иерархические справочники при правильной постановке процесса, как говорил Пелевин, на..й не нужны. Сделать то их можно с разной степенью полезности, но можно прекарсно обходиться без них.
Далее, согласен с остальными отвечающими: мож сначала подумать над процессом и как потом с данными работать, а затем думать как всё это сделать?

[xan]

Конечно же надо верить :-)))

Это же ЫЩО один очередной партнер, который "делает как умеет и что умеет", и не важно что надо клиенту, важно что у него есть.


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

[StoneRoller]

Цитата:

Изначально опубликовано xan
Конечно же надо верить :-)))

Это же ЫЩО один очередной партнер, который "делает как умеет и что умеет", и не важно что надо клиенту, важно что у него есть.


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

никак основной армейский принцип в ход пошел?

[Клиент]

bucken: Ресурсы, кроме времени (нужно успеть 1 января), практически не ограничены.

А можно уточнить в чем возникает проблема при использовании фискального регистратора в Аксапте? Долго "прикручивать" или сложности уже при работе?
Вопрос, конечно, чисто технический, но все же...
Я так думал, что если Аксапта может работать с ActiveX, то и сложностей быть не должно. Или как?

xonix: А в качестве "простенькой программы" предлагается Досовская задача и обмен с ней через текстовый файл.

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

[xonix]

2 Клиент

Вот вы интересный товарисч ( в хорошем смысле)
НЕ НАДО прикручивать к Аксапте ФР. По причине того, что не нужны Аксапте (и Вам) данные от него с такой полнотой, которую будет делать Аксапта (проводки во всех журналах)

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

Удобство для аналитики - это здорово! Особенно, если учесть, что у аксапты нет отчётов, которые учитывают "древовидность". Т.е. отчёты тоже переделывать придётся. А по сему вопрос: мож разработать систему признаков, по которым делать аналитику потом, и признаки присобачить к карточке клиента? Оно позволит "делать аналитику" куда лучше (измерений больше, чем в дереве).
Коряво будет выглядеть как раз с деревом.

[StoneRoller]

2 Клиент: использование древовидных справочников дело привычки. после 1с тоже казалось что без них не обойтись. потом привыкли и искренне не понимаем - нафига она нужна)) в аксапте достаточно механизмов реализовать отчетность в нужной форме

[Lazy_Tiger]

1) Такие решения (для розничной торговли) есть ГОТОВЫЕ. НЕНУЖНО ИЗОБРЕТАТЬ ВЕЛОСИПЕД. У нас (компания ФОРС, г. Красноярск) внедрено решение Axapta Retail от Корус-Консалтинг.
Есть еще Retail Manager for Axapta от Columbus, но это всего лишь Axapta Retail от Коруса для аксапты версии 2.5 поднятая Колумбусом на аксапту 3.0
2) Иерархические справочники сделать можно, для справочника номенклатуры простейшее решение можно сделать минут за 40
3) Фискальные регистраторы подключить можно, например у нас MSTAR-Ф

P.S. Остальное в аську или почту...

[Клиент]

2 StoneRoller : Конечно, вопрос решаемый и при большой цене вопроса будет использоваться другой подход, компромиссный.
У нас пока крутится своя разработка. К ней, конечно, все уже привыкли. Просто хотелось сохранить подход, анализ. Но раз это приведет к большим временным трудозатратам, то конечно, настаивать не буду.


2 xonix : Я не совсем понимаю термин - проводки во всех жураналах.
А данные мне нужны "во всей полноте".
Маркетинговая служба очень активная и изощренная
В частности ей интересны и номер чека и время продажи.

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

[xonix]

2 Клиент

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

Полнота данных, весч хорошая. Так и организуйте маркетологам ОДНО хранилище, в которое надо вываливать данные из продажной программы, а на нём наковыряйте кубиков. (им же только факты продаж надо анализировать, маркетологам то этим )
И пусть там смотрят номера чеков, и т.д. А заодно и продажи во всех разрезах - быстро и удобно.

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

Не устраивает этот терминал - ищите другой...

[xonix]

Если денег много - можно конечно и на аксапте наваять ОТДЕЛЬНЫЙ модуль, который будет регистрировать продажи. И ежедневно консолидировать данные по товарам/ценам и заливать в модули логистики и финансов. Но имхо отдельная ГОТОВАЯ прога выйдет дешевле...

[Клиент]

2xonix : Собственно, ОТДЕЛЬНЫЙ модуль и заказываем. Только разработчики сопротивляются. Говорят: все сделаем, кроме фискального регистратора.
Отсюда и родился вопрос.

Lazy_Tiger : Спасибо. Обращусь

[Андре]

Цитата:

-Аксапта не умеет работать с подключенным
по Com-порту фискальным регистратором.

Стандартная не умеет. Но написать можно и не сложно.
Более того, если писали для одного типа регистратора, то переделать под другой - совсем не сложно.

[Alks]

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

1. Кассовый сервер на Axapta - чем плох?? Изначально мы планировали реализовывать кассовый сервер именно на Axapta, и сделали бы, если бы укладывались в сроки. В будущем, если купленный кассовый сервер не будет устраивать, всё равно реализуем. Аргумент о том что нефиг так делать, ибо база будет быстро разрастаться имеет смысл (например в нашей старой системе на 1С объём данных документов Чек и его проводок составляет примерно 90% от объема всех остальных документов и их проводок), но разве нельзя выработать компромиссное решение - сами чеки хранить в отдельных таблицах с признаком "разнесен", а разнесение чеков выполнять как batch процедуру, которая из всех чеков за день сформирует тот самый один блок проводок с умеренной детализацией. Это полюбому лучше, чем возня с обменом, да и мониторинг всей системы в целом проще становится и монолитнее. Да и самое главное - сопряжение аксаптовских номенклатурных аналитик и прайс-листа со сторонним кассовым сервером для меня видится задачей нетривиальной, если вообще возможной.
2. Ох уж этот древовидный классификатор. Действительно в 1С к древовидности справочников привыкаешь и как потом без неё обходится понятия не имеешь. Причём если заглянуть в структуру таблиц, которую создаёт 1С в СУБД, то видно что древовидность там реализована крайне просто - если "кол-во уровней" в справочнике > 1, то в таблице справочника появляются два поля: ISGROUP и PARENT, и ничего более.
У меня (как и у наших составителей бизнес-процессов, работавших с коламбусом) в основном 2 вопроса:
1. Как манагеру быстро отфильтровать в справочнике из более чем 40000 номенклатур список "Лакокрасочной продукции \ Красители \ Машинные красители \ Пигментные пасты" не используя древовидный подход?? У нас 4-уровневая детализация из которой первые 2-3 уровня будут очень активно использоваться при подборе товара и выведению отчетов для анализа работы отделов, и отдельных товарных направлений (кстати имеющиеся в акспте отчёты были охарактеризованы руководством как "никакущие" и их всё равно придется переделывать), поэтому вопрос - как подобную задачу можно решать используя "плоский справочник"? Напихать в справочник товаров 4 новых аналитики и заполнять их? Но это же бред...
P.S.
Как известно большая часть нутра Аксапты написана на самой же Аксапте, тут у меня возникает вопрос - если в такой задаче, как управление предприятием и анализ его работы можно обойтись плоскими таблицами-справочниками, то почему ими нельзя было обойтись в такой задаче, как управление проектами / AOT-ом?

[Hamster]

ТЗ на разработку или на внедрение?

Это 2 бааальшие разницы...

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Alks
Как манагеру быстро отфильтровать в справочнике из более чем 40000 номенклатур список "Лакокрасочной продукции \ Красители \ Машинные красители \ Пигментные пасты" не используя древовидный подход??

Обсуждалось неоднократно.

http://www.axforum.info/forums/showt...&threadid=2130
http://www.axforum.info/forums/showt...&threadid=1614

От себя: никто не говорил, что принципиально иерархическая классификация в Axapta невозможна - вопрос в ресурсах.

Цитата:

Изначально опубликовано Alks
Как известно большая часть нутра Аксапты написана на самой же Аксапте, тут у меня возникает вопрос - если в такой задаче, как управление предприятием и анализ его работы можно обойтись плоскими таблицами-справочниками, то почему ими нельзя было обойтись в такой задаче, как управление проектами / AOT-ом?

А кто сказал, что это не "плоские таблицы"? См. UtilElements и UtilIdElements.

[xonix]

2 Alks
Задача сопряжения в данном случае не сложная. Не буду углубляться в детали, вкратце - в одну сторону идут справочники (и только они), в другую - факты (неизменные, т.е. не надо поддерживать UPDATE ).
Так вот, в этом свете использование готового ПО предпочтительней разработке нового (для стандартной задачи - кассы). Кроме того, X++ не самое удобное средство разработки для подобных задач.
Ваш способ реализации такой задачи на Аксапте правильный. Весь вопрос в том, что в описанном случае такую работу (разработку) предстоит выполнять внешним программерам по 60-80 долл/час. С учётом проектирования, прототипирования, разработки, полного тестирования недёшево получится.

2. Справочники.
Вы тогда определитесь.. Вот товарисч говорит, что ему "дерево" для аналитики надо.
Вы разницу между задачей быстрого поиска в классификаторе, и аналитики поверх дерева чувствуете?
Для поиска можно продумать классификацию товаров, где 2-х буквенные аббревиатуры определяют уровень дерева. Ой.. вам уже указали на ветки, где это обсуждалось.
Для "быстрого поиска" дерево (как вариант) тоже подходит. Программируется нетрудно (но только для поиска). Кроме того, можно много чего напридумывать, решая задачу именно быстрого поиска товаров. Например, держать список "часто используемых товаров", который будет обеспечивать 80% попадание. Эээх..
Что вы всё в кучу то мешаете?

П.С. Неужто в КОламбусе это действительно те вопросы, над которыми они с таким опытом внедрения "думают"?

Как руководство отчёты характеризует - то это им видней, конечно. Уверен, что и отчёты вашего руководства в другой компании тоже могут назвать "никакущими".

А как программиста я вас понимаю...