Результаты круглого стола на встрече пользователей 19.11.04

Автор Сообщение
aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 30.11.2004 14:37 Заголовок сообщения: Результаты круглого стола на встрече пользователей 19.11.04
Коллеги,

19 ноября в Питере прошла встреча пользователей Скалы. На круглом столе были озвучены 25 тем, по которым хотелось бы увидеть улучшения. Перечень предложений направлен на Горячую Линию и вот появились первые результаты.

Для начала сам список:
1. Необходимо иметь возможность импорта проводок типа 03 (затраты) в модуле «Управление запасами». В настоящее время возможен импорт всех типов проводок, кроме проводок типа 03.
2. Возможность импорта проводок SC может быть использована как альтернатива процедуре Stock Rebuilt, однако, в настоящий момент это невозможно из-за отсутствия импорта проводок по затратам (см. п.1)
3. Возможность полного копирования (вместе с заголовками) заказов. Копирование ЗЗ -> ЗЗ, ЗЗ -> ЗП, ЗП -> ЗП, ЗП -> ЗЗ. Как альтернативу или дополнение можно рассматривать шаблоны заказов.
4. Возможность перемещения (не копирования!) строк из одного заказа в другой.
5. В схеме автоучета модуля SC необходимо предусмотреть дополнительную позицию для учета излишков по результатам инвентаризации. В настоящее время рассчитывается только недостача. Прилагается документ «reqrusStockTaking.doc»
6. Возможность изменения склада в заказах на продажу/закупку, по которым еще не произведены оприходование или отгрузка запаса со склада.
7. Необходима возможность сортировки проводок в списке проводок по запасам. В настоящее время при параметре «В порядке даты» =Да, система производит сортировку проводок внутри каждой даты по типам проводки, что совершенно не логично.
8. Необходимо иметь дополнительный вид заказа – заказ на перемещение со склада на склад. Кроме того, необходимо сохранять историю перемещений. Прилагается документ «reqrus144Lengaz.doc»
9. Проблема качества – проблема урезания полей. Например: описание склада – 35 символов. При выводе на экран по F4 название обрезается до 20-ти символов. Прилагается документ «Урезание полей.doc»
10. Проблема нехватки кодов автоучета (ограничение – 41 код автоучета). Предлагается увеличить до 100 кодов (с 00 по 99), а лучше использовать для формирования кода автоучета трехмерную матрицу по типу матрицы скидок запасов/покупателей, где на пересечении строк и столбцов находится таблица из 10 (с учетом предложения п. 5) значений позиций автоучета:

Код:
1. Полученные Запасы
2. Начисленный Приход
3. Начисленн.Затраты
4. Выданные Запасы
5. Начисленный Расход
6. Инвентар. Разница (недостача)
7. Закупочная Разница
8. Затр.на Приобретение
9. Переоценка
10. Инвентар. Разница (излишки)


11. Построение отчетов с заданием критерия выборки по маске как альтернатива или дополнение к заданию критерия выборки по интервалу кодов – везде, во всех модулях.
12. Необходим дополнительный тип распределения затрат по заказу на закупку – пропорционально цене, умноженной на некий коэффициент, который можно было бы задавать в карточке позиции запаса.
13. Возможность ввода распределения затрат по нескольким выбранным заказам на закупку, а также по выбранным строкам заказов на закупку суммарно, без необходимости указывать отдельную сумму для каждого заказа и/или строки.
14. Пересмотреть ограничения на количество знаков после запятой в некоторых полях, в первую очередь для коэффициентов пересчета одних единиц измерения в другие, для ценовых коэффициентов и т.д. Все перечисленное хранится в базе данных с точностью до 8 знаков после запятой.
15. Необходимо древовидное представление списка запасов.
16. Необходим генератор кодов запасов (параметрический, в зависимости от свойств запаса).
17. При вводе заказов на продажу использовать левый и правый grid.
18. Неудобно вводить коды покупателей и поставщиков. Максимальная длина кода – 10 символов. Система позволяет вводить 12 символов, выдавая при этом сообщение ‘Supplier code length should be between 2 and 10’. Прилагается текст письма в R&D
19. Все счетчики англоязычные при том, что Скала – система многоязычная.
20. Встроенный калькулятор не округляет значения, а просто обрезает цифры.
21. Проблема качества. «Плавающий» интерфейс. Ширина полей не фиксируется, обрезаются длинные числа и названия.
22. Проблема качества. При работе через терминальный доступ в классическом интерфейсе подсвечивание полей (например, при вводе платежей покупателям) отображается как точки. Следовательно, совершенно не видна информация в поле.
23. Кнопки «Далее» и «Назад» работают не везде.
24. По возможности переименовать кнопку «Уничтожить» (при печати отчетов).
25. Функция Attach Company вынесена отдельной позицией в лицензии. Возникает большое количество недоразумений. Очень неудобно.

А вот, что получено на данный момент от Хотлайна:
пп. 1-2 — запрос на новую функциональность reqrus56, Benjamin 66349
п. 5 — запрос на новую функциональность reqrus147, Benjamin 59257
п. 8 — запрос на новую функциональность reqrus144, Benjamin 66328
п. 9 — bug сейчас «репортится»
п. 18 — bug Benjamin 66499 — заново открыт с комментариями клиента
(кстати, вот текст упомянутого письма в R&D:

Цитата:
Уважаемый Аналитик,

СоюзБалтКомплект, который я представляю, считает абсолютно неприемлемым, как само отклонение заявленной проблемы, так и комментарий подобного рода:
«The additional 2 positions are needed to enter specsymbols #+ for the entry of the standard customer/supplier. Otherwise standard customer supplier code will be limited with 8 symbols So the only way is to allow 12 symbols entry and then check the length with the error message»
Поясню почему:
1. Вы совершенно не принимаете во внимание частоту использования ввода поставщика (покупателя, запаса) и шаблона поставщика (покупателя, запаса). Если принять первое за 100%, то второе обычно составляет не более 1%, разве что за исключением ввода нового запаса по шаблону на базе существующего (с командой #*)
2. Некорректность отказа состоит прежде всего в том, что абсолютно игнорируется проблема клиента, взамен дается другая проблема. А это уже, простите, меня, как клиента, не очень волнует. Однако, я легко могу предложить варианты, над которыми Вы просто не захотели подумать, ибо отказать гораздо проще, чем что-либо предлагать, а тем более делать. Итак, предлагаемые альтернативы:
а) воспользоваться тем же принципом, как и при удалении кодов, когда пользователю предлагается ввести минус и нажать Enter. Программа переключается в режим удаления. Такой принцип особенно удобен, в случае создания нового запаса на базе существующего, когда пользователь вынужден «на память» вводить код существующего запаса, например, #*10/ФП/НОЧЕМИЛ/2037-12314. Согласитесь, ввести такое руками весьма проблематично, более удобно было бы ввести #*, нажать Enter, экран бы переключился в форму выбора запаса из списка, а уже после выбора из списка вернуться в основную форму. Разумеется, то же касается и ввода Поставщика или Покупателя. Аналогично и с командой #+ (Вводим #+, нажимаем Enter, программа переключается в режим ввода стандартного поставщика (покупателя, запаса). Вводим код и дальше все, как обычно).
б) Даже, если предположить, что п. а) неприемлем, тогда следовало бы на попытку ввода кода поставщика (покупателя) длиной более 10 символов не просто «ругнуться» и стереть введенный код, а «ругнуться» и предложить урезать его до 10 символов. Думаю, что это устроило бы пользователя в 95% случаев. Тем более это верно и для ввода запасов, где введенный код может быть особенно длинным.
в) думаю, что нетрудно найти и другие варианты, главное, чтобы пользователю не приходилось заново вводить новый код, высчитывая в уме его длину. Попробуйте поставить себя на место пользователя. (Чтобы Вам было более понятно, скажу, что коды поставщиков и покупателей у нас не цифровые, а буквенные, например, КОМПТРИАЛ для «ТОО «Компания Триал», только не предлагайте переделать их в цифровые или что-нибудь в этом роде)

Вы же ничего не сделали для решения возникшей у нас проблемы! Просто срежектили Benjamin 64499, прикрывшись неудовлетворительным комментарием.
Не думаю, что это верный путь.

С уважением,
Алексей Васильев,
СоюзБалтКомплект


письмо было отправлено при отказе R&D признать заявленную проблему к исполнению)

Остальные 19 пунктов будут переданы на рассмотрение.
Вот такие новости на данный час. Я буду информировать Вас при поступлении новой информации на этот счет.

aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 22.12.2004 17:08 Заголовок сообщения: Re: Результаты круглого стола на встрече пользователей 19.11

Алексей Васильев ранее писал(а):
14. Пересмотреть ограничения на количество знаков после запятой в некоторых полях, в первую очередь для коэффициентов пересчета одних единиц измерения в другие, для ценовых коэффициентов и т.д. Все перечисленное хранится в базе данных с точностью до 8 знаков после запятой.


Пока суть да дело, а R&D думает, нас с vome достали отваливающиеся VBA проекты, написанные консультантами Скалы, для ввода ценовых коэффициентов для закупок и коэффициентов для преобразования одних единиц измерения в другие до 8 знаков после запятой. Проекты отключили и решили пойти другим путем: для изменения первого пошла в ход правка «напрямую» в базе данных поля SC10025 на 8. Для второго пришлось откорректировать строки LAN файлов (в административной консоли):
Соответственно:
123 строка — 14 61 138 69 08 00 95
126 строка — 15 61 139 69 08 00 95
129 строка — 16 61 140 69 08 00 95
132 строка — 17 61 141 69 08 00 95
135 строка — 18 61 142 69 08 00 95
пятая с конца цифра и есть то самое необходимое кол-во знаков после запятой ( 8 ).
Если б Вы знали, какое это облегчение для нас! Ща как дам больно!..

aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 01.02.2005 18:32 Заголовок сообщения: 8 знаков после запятой — не так-то просто

aav писал(а):
Проекты отключили и решили пойти другим путем: для изменения первого пошла в ход правка «напрямую» в базе данных поля SC10025 на 8.


Пришлось изменить на 6, так как эта зараза использует сие значение и для поля «Цена за» в заказах на закупку и продажу. Длина поля 10 символов минус установленные нами 8 знаков после запятой, минус сама запятая, итого остается один символ, т.е. не удается ввести значение больше, чем 9.99999999. С 6 знаками после запятой — соответственно 999.999999

aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 27.10.2005 08:20 Заголовок сообщения: Знает ли кто-нибудь какие-либо новости по списку вопросов?
Коллеги,

Если кто-то из Вас часто общается с хотлайном, не поинтересуетесь ли Вы о статусе того списка, что приведен в самом начале сообщения: что сделано для SR1, что реализовано в SR2, что ожидается в ближайшем будущем и когда?

vome
Народный форумщик

Зарегистрирован: 17.09.2004
Сообщения: 210
Откуда: Санкт-Петербург -> Москва

Добавлено: 02.11.2005 17:38 Заголовок сообщения: Re: Результаты круглого стола на встрече пользователей 19.11
Ответ Хот Лайна о статусе данного списка:

aav писал(а):
Для начала сам список:
1. Необходимо иметь возможность импорта проводок типа 03 (затраты) в модуле ‘Управление запасами’. В настоящее время возможен импорт всех типов проводок, кроме проводок типа 03.

Benjamin 66349
66349 Y N N No Import for 03 transactions in SC can be done (reqrus56) 07/12/2004 14:31:45 Frozen iScala 2.2
This is an enahncment. Possibly to import additional costs using connectivity but not using flat file import. This issue is currently Frozen as connectivity provides a work around, but can be considered for future version if escalated with supporting business case

Цитата:
2. Возможность импорта проводок SC может быть использована как альтернатива процедуре Stock Rebuilt, однако, в настоящий момент это невозможно из-за отсутствия импорта проводок по затратам (см. п.1)

Benjamin 66349
No Import for 03 transactions in SC can be done (reqrus56)
07/12/2004 14:31:45 Frozen iScala 2.2
This is an enhancement. Possibly to import additional costs using connectivity but not using flat file import. This issue is currently Frozen as connectivity provides a work around, but can be considered for future version if escalated with supporting business case

Цитата:
3. Возможность полного копирования (вместе с заголовками) заказов. Копирование ЗЗ -> ЗЗ, ЗЗ -> ЗП, ЗП -> ЗП, ЗП -> ЗЗ. Как альтернативу или дополнение можно рассматривать шаблоны заказов.

Benjamin 66424
Improve Purchase Order Function 07/12/2004 14:25:30 NextVersion iScala 2.2
Consider for future version unless escalated
Benjamin 66529
Improve OR Function 15/02/2005 22:05:28 NextVersion iScala 2.2
Consider for future version unless escalated
Requested functionality:
Adjustments and Functionality additions to be done in Enter/Adjust order routine
1. Change procedure of order lines identification in order user could quickly find and search through the order lines. Add sorting of order lines by stock code, by stock item description, warehouse code, delivery date. Scrolling of order lines is highly required instead of listing 6 order lines per page.

2. Add functionality to search order lines by stock code with possibility to select this line in order to do adjustments like correction, deletion, entering of delivery etc

3. Add Search templates like in sql (???red*) for stock code and stock item description
for order lines selection
4. For order line without delivery should be possible to change warehouse
5. Having Copy order function, similar to the one which exists in SM, able to copy orders together with Headers.
6. Having Order Templates available
7. Being able to move (copy and then get deleted) order lines from one order to another.
Current functionality:
Absence of all stated above, very poor 6 order lines listing dialog — it is very difficult to work with a large orders, you can not change warehouse for existing order lines, copy functions are poor.

Цитата:
4. Возможность перемещения (не копирования!) строк из одного заказа в другой.

Benjamin 66529
Improve OR Function 15/02/2005 22:05:28 NextVersion iScala 2.2
5. Having Copy order function, similar to the one which exists in SM, able to copy orders together with Headers.
7. Being able to move (copy and then get deleted) order lines from one order to another.
Consider for future version unless escalated

Цитата:
5. В схеме автоучета модуля SC необходимо предусмотреть дополнительную позицию для учета излишков по результатам инвентаризации. В настоящее время рассчитывается только недостача.

Benjamin 66328
Additional line required for Stock Taking in AAS (reqrus147)
14/05/2005 15:25:11 Release iScala 2.2 B SR2 2758 18/05/2005

Цитата:
6. Возможность изменения склада в заказах на продажу/закупку, по которым еще не произведены оприходование или отгрузка запаса со склада.

Benjamin 66529
Improve OR Function 15/02/2005 22:05:28 NextVersion iScala 2.2
4. For order line without delivery should be possible to change warehouse
Consider for future version unless escalated

Цитата:
7. Необходима возможность сортировки проводок в списке проводок по запасам. В настоящее время при параметре ‘В порядке даты’ =Да, система производит сортировку проводок внутри каждой даты по типам проводки, что совершенно не логично.

Записей по данному вопросу нет — пришлите номер или корреспонденцию с Хотлайном. Думаю был Reject

Цитата:
8. Необходимо иметь дополнительный вид заказа — заказ на перемещение со склада на склад. Кроме того, необходимо сохранять историю перемещений.

Benjamin 59257
New OR type required (reqrus144)
04/08/2005 10:12:01 NextVersion iScala 2.2

Цитата:
9. Проблема качества — проблема урезания полей. Например: описание склада — 35 символов. При выводе на экран по F4 название обрезается до 20-ти символов.

Записей по данному вопросу нет — пришлите номер или корреспонденцию с Хотлайном. Думаю был Reject

Цитата:
10. Проблема нехватки кодов автоучета (ограничение — 41 код автоучета). Предлагается увеличить до 100 кодов (с 00 по 99), а лучше использовать для формирования кода автоучета трехмерную матрицу по типу матрицы скидок запасов/покупателей, где на пересечении строк и столбцов находится таблица из 10 (с учетом предложения п. 5) значений позиций автоучета:

Код:
1. Полученные Запасы
2. Начисленный Приход
3. Начисленн.Затраты
4. Выданные Запасы
5. Начисленный Расход
6. Инвентар. Разница (недостача)
7. Закупочная Разница
8. Затр.на Приобретение
9. Переоценка
10. Инвентар. Разница (излишки)

Benjamin 66559
Not enough numbers for accounting codes in Stock Module (41 is not enough). 15/02/2005 22:07:02 Frozen iScala 2.2
This enhancement request is frozen until it is escalated

Цитата:
11. Построение отчетов с заданием критерия выборки по маске как альтернатива или дополнение к заданию критерия выборки по интервалу кодов — везде, во всех модулях.

Benjamin 66623
Enhancing to Mask usage for Stock codes, in reports Selection criteria 15/12/2004 08:55:12 OnHold iScala 2.2
This would be a very nice feature, may be worth getting an estimate. Note: SnapSearch allows wildcard selection using the SQL %.

Цитата:
12. Необходим дополнительный тип распределения затрат по заказу на закупку — пропорционально цене, умноженной на некий коэффициент, который можно было бы задавать в карточке позиции запаса.

Benjamin 66620
New PO cost allocation enhancements 02/08/2005 14:58:00 Design iScala 2.2
1. It could be very nice to have an option to enter PO cost allocations for several purchase orders and several order lines with out splitting amounts by orders or lines but totally i.e one amount per few orders or/and lines.
2. It could be very nice to have an option to enter PO cost allocation based on purchase price proportionally and multiplied by custom coefficient which should be set up in stock item card.

There is no such functionality at the moment
Option 1 is implemented in SR2, is is possible to allocate cost per DN and GRN (and GRN can cross order boundaries)
Option 2: Workaround is to use Weight/Volume parameters as factors

Цитата:
13. Возможность ввода распределения затрат по нескольким выбранным заказам на закупку, а также по выбранным строкам заказов на закупку суммарно, без необходимости указывать отдельную сумму для каждого заказа и/или строки.

Benjamin 66620
New PO cost allocation enhancements 02/08/2005 14:58:00 Design iScala 2.2
1. It could be very nice to have an option to enter PO cost allocations for several purchase orders and several order lines with out splitting amounts by orders or lines but totally i.e one amount per few orders or/and lines.

2. It could be very nice to have an option to enter PO cost allocation based on purchase price proportionally and multiplied by custom coefficient which should be set up in stock item card.

There is no such functionality at the moment
Option 1 is implemented in SR2, is is possible to allocate cost per DN and GRN (and GRN can cross order boundaries)
Option 2: Workaround is to use Weight/Volume parameters as factors

Цитата:
14. Пересмотреть ограничения на количество знаков после запятой в некоторых полях, в первую очередь для коэффициентов пересчета одних единиц измерения в другие, для ценовых коэффициентов и т.д. Все перечисленное хранится в базе данных с точностью до 8 знаков после запятой.

Benjamin 66632
Number of Decimals for coefficients and price multipliers
23/06/2005 12:36:02 Closed iScala 2.2
No possibility of this being done in the short to medium term

Цитата:
15. Необходимо древовидное представление списка запасов.

Benjamin 66563
Tree like structure of Stock Item listing (Similar to the one we have in BOMs) 15/02/2005 22:03:56 NextVersion iScala 2.2

Цитата:
16. Необходим генератор кодов запасов (параметрический, в зависимости от свойств запаса).

Записей по данному вопросу нет — пришлите номер или корреспонденцию с Хотлайном. Думаю был Reject

Цитата:
17. При вводе заказов на продажу использовать левый и правый grid.

Записей по данному вопросу нет — пришлите номер или корреспонденцию с Хотлайном. Думаю был Reject

Цитата:
18. Неудобно вводить коды покупателей и поставщиков. Максимальная длина кода — 10 символов. Система позволяет вводить 12 символов, выдавая при этом сообщение ‘Supplier code length should be between 2 and 10’.

This was not from the Group but from Alexey Vasiliev personally and it was fixed and he was informed about it.
Неправильный номер — он занесен на другую тему и от другого клиента.
Benjamin 66614
Entered code to be saved after warning message 21/12/2004 09:10:56 Release iScala 2.2 B SR1HF2250, SR2 Alpha1 31/12/2004

Цитата:
19. Все счетчики англоязычные при том, что Скала — система многоязычная.

Ответ разработчиков — Не будет поддерживаться в ином варианте

Цитата:
20. Встроенный калькулятор не округляет значения, а просто обрезает цифры.

Ответ разработчиков — Не будет поддерживаться в ином варианте

*********************
Пункты, указанные далее не поступали в изначальной заявке от Круглого стола и соответственно не были рассмотрены с изначальной заявкой.

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

Цитата:
21. Проблема качества. ‘Плавающий’ интерфейс. Ширина полей не фиксируется, обрезаются длинные числа и названия.


Цитата:
22. Проблема качества. При работе через терминальный доступ в классическом интерфейсе подсвечивание полей (например, при вводе платежей покупателям) отображается как точки. Следовательно, совершенно не видна информация в поле.

Репортить как багу

Цитата:
23. Кнопки ‘Далее’ и ‘Назад’ работают не везде.

Репортить как отдельные багги для каждого случая через Хотлайн

Цитата:
24. По возможности переименовать кнопку ‘Уничтожить’ (при печати отчетов).

Зарепорчена как Лан бага — проверить в СР2 September ХФ, если опять не поправлена зарепортить на Хоталйн еще раз

Цитата:
25. Функция Attach Company вынесена отдельной позицией в лицензии. Возникает большое количество недоразумений. Очень неудобно.

Это вопрос не к нам а к отделу продаж касательно политики лицензирования.

Так получается, что на данный момент воплощено 1 пожелание и исправлена 1 бага.
Хотя на конференции 26 октября 2005 г. Был представлен модуль «Управление запросами(требованиями)» пришедший из Гостиничного бизнеса, который, кроме всего прочего, можно считать как воплощение заказа на перемещение. Во всяком случае из этого модуля можно получить историю перемещений и копировать их.

И почему то все пожелания User Group зарегистрированы как поступившие от одного клиента, который в настоящее время перестал пользоваться поддержкой Скала. И, как говорят на Хот Лайне, стало тяжелее продвигать наши пожелания в жизнь. Хотя пользователь User Group в систему заведен.
Поэтому предлагаю на ближайшей User Group вновь поднять вопрос о актуальности данного списка, возможно с добавлением новых идей, пожеланий.

aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 07.11.2005 11:29 Заголовок сообщения: Re: Результаты круглого стола на встрече пользователей 19.11

vome писал(а):
NextVersion iScala 2.2

Перевод со «Скальского» на русский — «в следующей жизни» (или «никогда»)