Извечный вопрос: кодить или параметризовать.

[AKIS]

Цитата:

Изначально опубликовано Fisher
Ничего себе.
Вы господа внедренцы получается точно знаете,
что нужно клиенту не интересуясь его мнением.
Вы считаете что процессы реализванные в Axapte абсолютно оптимальны и непогрешимы.
Задача ИТ отдела - оптимизация процессов, а не перепроектирование или реинжиниринг.
Это совершенно другие задачи,
ими занимаются другие специалисты

С клиентом, безусловно, советоваться надо - но идти у него на поводу во всем это верх глупости.

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

С другой стороны - Заказчик что, тоже в свою очередь считает что ЕГО процессы непогрешимы?

Я не понимаю одно: зачем вообще внедрять какую-то систему, если есть уверенность что все работает как надо и без нее?

[Fisher]

Всё именно так, как вы сказали.

[Fisher]

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

[Тимур]

Разумеется, если Вы имеете дело с людьми, не владеющими предметными знаниями и опытом.
И часто бывает так, что системные интеграторы лезут туда, куда не следует.
Тем не менее, в западных программных продуктах заложены апробированные бизнес-модели. Не с потолка же люди писали системы.
Ну а про уникальность процессов управления на каждом предприятии очень хорошо сказал "оракул" Ларри Элисон.
Если уникальность в "кривизне" процессов - то не факт, что именно эта "кривизна" приносит вашему предприятию прибыль.

[ushastik]

Мы все как-то в общих словах. Давайте попробуем поконкретнее. Есть склад. Там лежит кабель. В бобинах. Бобины в ячейках. Надо учитывать как общий метраж, так и каждую бобину в отдельности, бобины могут содержать разный метраж изначально, в производство можно списать часть бобины. Кроме того для каждой бобины измеряются электрические характеристики. Как это учитывать в Аксапта ?
1. Норма упаковки не подходит, так как при оприходовании каждую бобину промеряют (длина разная). Кроме того одна полная бобина != 10 полупустых, даже если метраж совпадает.
2. Каждая бобина - отдельная номенклатура - неудобно отбирать бобины с одинаковыми характеристиками. Например, надо 20 километров кабеля, это 5 целых бобин плюс половина, резервируются одной операцией.

Вопрос, где кривизна в моих бизнес-процессах ?
Вопрос, как без доработки обойтись стандартным функционалом ?

[AKIS]

Задача, кстати, не такая уж уникальная.
Сравните: Есть склад, там лежат банки... ну скажем с краской, они стоят на паллетах. Число банок на паллете может быть разным в зависимости от кода номенклатуры, плюс может отпускаться неполная паллета.

Задача: учитывать как количество банок, так и количество паллет.

Решение: добавляем код номенклатуры "паллета", создаем BOM на каждый код материала с участием паллеты.

Все работает прекрасно - и никакого кодирования!

[ushastik]

За тем лишь исключением, что палетте придется присвоить несколько электрических характеристик Так как приходит партия, номенклатура одна, катушки отдаются на контроль и сортируются по характеристикам . Кроме того никто не должен смочь переложить кабель в другую палетту. Но в принципе, наверное Вы правы.

[AKIS]

Присвоение электрических характеристик - это, как я понимаю, задание определенных параметров строки заказа на покупку, а потом сортировка-группировка по ним. То есть, говоря языком программиста, присвоение значений некоторым полям таблиц PurchLine / InventTrans / Purch Receiptlist / PurchPackingSlip... В принципе, конечно, можно эти поля просто создать. Но я бы все ж таки не поддался на такое искушение, а попытался использовать существующие.

Вопрос, который нужно проработать очень детально: а насколько электрические характеристики влияют на логистический процесс? Понимаю, что ответ сходу будет "жить без них не можем". Но я бы не брал этот ответ сходу. Я бы предложил: давайте попробуем обойтись без них ВООБЩЕ. Ну не знаем мы их, и знать не хотим, мы приходуем-перемещаем-продаем определенный ТОВАР, а какое у него сопротивление - пусть главный инженер репу чешет. У ТОВАРА есть довольно ограниченный набор характеристик: себестоимость, цена, масса, размеры, единицы измерения. Бывает полезно поставить себя в эти ограничения, и попытаться какое-то время в них "пожить"....

[spy]

Пожалуй, выскажу свою мысль. Возможно она будет и не очень удачной

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

[ushastik]

1. Не в заказе, а по приходу на склад. У нас такие поставщики, что в одной партии идут разные катушки, их проверяют на складе, ПОСЛЕ ПРИХОДА, и потом делят на группы. Зато эти поставщики дешевые, и это нас устраивает, и требовать сотрировки от них бесполезно - ро русски не понимают
2. Без характеристик прожить можно. Можно вообще прожить без адресного склада. Поставить финансы в главном офисе и праздновать Но хочется не просто Аксапту внедрить, а ПО МАКСИМУМУ АВТОМАТИЗИРОВАТЬ процессы, которые автоматизировать можно. То есть обработать такие заказы:
- выдайте мне 5 км. кабеля одним куском
- выдайте мне 20 км. кабеля в кусках не короче 3 км.
Аналогия с банками тут не очень работает - мне не все равно, брать целую катушку, или 3 полупустых. Более того, система должна автоматически зарезервировать катушки ОПТИМАЛЬНО, то есть пытаясь сначала начатые отпускать, если нет - тогда целые. Все это не трудно написать, но это доработки.

[ushastik]

2 spy:
И это будет совершенно правильно, только в заказе это одна обобщенная номенклатура, например "Кабель из Харькова", и приходуется по этой номенклатуре, а потом ее надо разбить на несколько реальных позиций. О, а это мысль, надо подумать в этом направлении

[spy]

Цитата:

Изначально опубликовано ushastik
Аналогия с банками тут не очень работает - мне не все равно, брать целую катушку, или 3 полупустых. Более того, система должна автоматически зарезервировать катушки ОПТИМАЛЬНО, то есть пытаясь сначала начатые отпускать, если нет - тогда целые. Все это не трудно написать, но это доработки.

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

[spy]

Цитата:

Изначально опубликовано ushastik
2 spy:
И это будет совершенно правильно, только в заказе это одна обобщенная номенклатура, например "Кабель из Харькова", и приходуется по этой номенклатуре, а потом ее надо разбить на несколько реальных позиций. О, а это мысль, надо подумать в этом направлении

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

[komar]

Господа, вопрос-то был - делать одну форму или несколько. А получилось опять "о вечном"...

[ushastik]

Цитата:

Изначально опубликовано komar
Господа, вопрос-то был - делать одну форму или несколько. А получилось опять "о вечном"...

Это точно, просто меня начали убеждать, что вообще кодить не надо, так что пришлось воевать

[AKIS]

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

Во-первых, при таких делах вам однозначно "светит" партионный учет, где 1 партия = 1 бобина, пришедшая от 1 поставщика. На партию уже навешиваются все нужные вам характеристики, по партиям ведется резервирование и пр.
Во-вторых, сделать "оптимальное резервирование" с учетом всех ваших требований - это писАть отдельную подсистему....

[George Nordic]

Опять отклоняемся от темы

Допустим, есть супер-форма, но она не устраивает юзеров. Менять сильно не хотим, т.к. не знаем, где стрельнет. Изменения в таблицах незначительны....
Берем эту форму, _дублируем_ её и ставим ей наше имя. Ищем перекрестные ссылки, и, там где есть вызов этой формы, меняем MenuItemы на наши, с сылкой на нашу форму. Потом делаем из неё супер-пупер форму, курочим её, пишем кучу фенек + распознование голоса, что б юзера были Щастливы, приходили к 10 и пили пиво.
Т.о. основной функционал мы не затронули - при переходе на новую версию у нас снова есть основа - исходная форма, и то, к чему надо стремиться и что править - наша расчудесная новая форма с голосовым управлением (+ пара классов к ней и временных таблиц для всяких пересчетов, может быть).

Правда, лишняя форма в функционале останется... неизвестно, какая

[ushastik]

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