Microinvest Форум Форуми Microinvest Форум
Microinvest Форум
 
 Въпроси/ОтговориВъпроси/Отговори   ТърсенеТърсене   ПотребителиПотребители   Потребителски групиПотребителски групи   Регистрирайте сеРегистрирайте се 
 ПрофилПрофил   Влезте, за да видите съобщенията сиВлезте, за да видите съобщенията си   ВходВход 

ДАЙТЕ ПРИМЕР Г-Н ПАВЛОВ

 
Създайте нова тема   Напишете отговор    Microinvest Форум Форуми -> Предложения
Предишната тема :: Следващата тема  
Автор Съобщение
dobronameren



Регистриран на: 05 Фев 2007
Мнения: 93

МнениеПуснато на: Пон Фев 26, 2007 09:05    Заглавие: ДАЙТЕ ПРИМЕР Г-Н ПАВЛОВ Отговорете с цитат

Ако искате във вашия форум да се работи конструктивно, делово и конкретно, ето ви възможност да дадете пример на всички, как при конкретно направени предложения, давате конкретни отговори, без да се увличате в ролята на белетрист. Очакваме отговорите. Предложенията ги знаете и са по-долу:

I. по ПРОГРАМАТА:

1. Премахване на грешката при задаване на автоматична номерация на документи по обекти.
2. Премахване на грешката за загуба на привързания към потребителя обект при смяна на базата и връщане отново в предишната база.
3. Въвеждане на предупреждение за изход от програмата.

Забележка: Неясно защо, програмата държи настройка за размера и включването на ДДС-то в цената на стоката, различна от тази на потребителите, т.е реципрочна. Не пречи при работата, но е смущаващо.

II. по ПРОЗОРЦИТЕ И ТАБЛИЦИТЕ:

1. Запомняне ширината на колоните и тази на прозореца след затварянето му и след затваряне на програмата до следващата промяна от потребителя.
2. Добавяне на бутон “refresh” за актуализация на съдържанието на таблица в отворен прозорец.
3. Добавяне на възможност за подреждане на колоните в таблицата със стоките по ред, зададен от потребителя или зададен от “master” потребител общо за цялата програма.
4. Добавяне на възможност за скриване на празните колони, или такива, които потребителя желае да скрие.
5. Добавяне на възможност за проверка на налично количество директно на намерените в "локатор", а също и такава възможност директно в прозорец на операция.

III. по АДМИНИСТРИРАНЕТО:

1. Добавяне на възможност за заместване на данни в колоните с наименованието, каталожните номера, баркодовете, както и в ценовите колони, по следната схема: редакция / заместване на данни - прозорец тип "импорт"; позициите, които се обработват се идентифицират по кода на стоката (тази колона не може да се замества), останалите колони се обработват само при наличие на данни, т.е. при посочване на N на колона от файла за импорт на заместващи данни.
2. Автоматично въвеждане на сумите в каса при импорт на операции.
3. Добавяне на стъпка при операция, за междинно запомняне състоянието на документа.
4. Премахване отварянето на празен прозорец след всеки импорт на операция.
5. Визуализиране на колоната с кода на стоката в прозорците на операциите и в тези за редакцията на документи.

IV. по ЦЕНОВИТЕ ГРУПИ И КАСОВИТЕ ОПЕРАЦИИ

1. Добавяне на възможност за въвеждане на доставни и продажни цени поне в една валута, които да се пазят в отделно именовани колони, подредени при ценовите колони, като валутните цени да могат да се използват както за директни операции в избраната валута така и да се конвертират в лева при избор на такъв вид работа от потребителя.
2. Добавяне на възможност да се следят касовите операции в касовата книга по потребител и по партьор.

V. по ВИЗУАЛНИ И ДИЗАЙНА:

ВИЗУАЛНО ПОГРАМАТА СТОИ ДОБРЕ.

Забележка:Може да се помисли за въвеждане на информационен бар за налични отворени прозорци, за да бъде резидентно на информационно разположение. А и не разбирам идеята проверката на работната база да е толкова трудно достъпна, а не на инфо-лентата.
Върнете се в началото
Вижте профила на потребителя Изпратете лично съобщение Изпрати мейла
Виктор Павлов
Microinvest
Microinvest


Регистриран на: 12 Авг 2002
Мнения: 21077

МнениеПуснато на: Пон Фев 26, 2007 13:49    Заглавие: Отговорете с цитат

I. по ПРОГРАМАТА:

1. Премахване на грешката при задаване на автоматична номерация на документи по обекти.
Отг. В следващата версия(3.01.008) тази грешка ще бъде отстранена. Получава се при натискане на бутона ‘Назад’ в прозореца за номерация на документите по обекти. Ако се върви по стандартната процедура и обектите се управляват последователно, по нарастващ ред, то този проблем не съществува.

2. Премахване на грешката за загуба на привързания към потребителя обект при смяна на базата и връщане отново в предишната база.
Отг. Може ли да ни предоставите малко повече информация, как точно се получава тази ‘тази загуба на привързания към потребителя обект’!?

3. Въвеждане на предупреждение за изход от програмата.
Отг. Ще бъде добавено такова предупреждение (3.01.009), което най-вероятно ще бъде обвързано с настройката за „Предупреждение за съхраняване на данните”.

Забележка: Неясно защо, програмата държи настройка за размера и включването на ДДС-то в цената на стоката, различна от тази на потребителите, т.е реципрочна. Не пречи при работата, но е смущаващо.
Отг. Настройката за „Цени с включено ДДС” се прилага само за базата данни, а не за всеки потребител. Не е възможно двама потребители да работят с различни методи на ДДС в цените. Неслучайно при избор на категорията „Специални” списъкът с потребителите се скрива. В момента работим над промени в модула с настройките, които ще ги направя по интуитивни за работа и по разбираеми от потребителите на програмата. Всичко това ще го документираме доста подробно. (3.01.009)



II. по ПРОЗОРЦИТЕ И ТАБЛИЦИТЕ:

1. Запомняне ширината на колоните и тази на прозореца след затварянето му и след затваряне на програмата до следващата промяна от потребителя.
Отг. Запомнянето ширината на прозореца работи и в момента. В прозореца за резултат от справките запомнянето на ширината на колоните работи в настоящата версия. Започваме постепенно прилагането на тази функция и в другите прозорци.

2. Добавяне на бутон “refresh” за актуализация на съдържанието на таблица в отворен прозорец.
Отг. Ще бъде добавен във версия (3.01.009)

3. Добавяне на възможност за подреждане на колоните в таблицата със стоките по ред, зададен от потребителя или зададен от “master” потребител общо за цялата програма.
Отг. Може да бъде направено, но е свързано с множество промени в настоящата архитектура на програмата, затова ще го отложим по назад в списъка с нещата, които ще добавим.

4. Добавяне на възможност за скриване на празните колони, или такива, които потребителя желае да скрие.
Отг. Версия 3.01.009 ще има такава възможност, но само в прозорците за операции. За в бъдеще може да си помисли и за другите прозорци.

5. Добавяне на колона с количествата в таблицата с намерените стоки в "локатор".
Отг. Може да бъде направено. Доста неясно ще е за количествата в кой обект става дума, но принципно може да се направи.


III. по АДМИНИСТРИРАНЕТО:

1. Добавяне на възможност за заместване на данни в колоните с наименованието, каталожните номера, баркодовете, както и в ценовите колони, по следната схема: редакция / заместване на данни - прозорец тип "импорт"; позициите, които се обработват се идентифицират по кода на стоката (тази колона не може да се замества), останалите колони се обработват само при наличие на данни, т.е. при посочване на N на колона от файла за импорт на заместващи данни.
Отг. Няма лесен начин да бъде реализирано! Винаги има едно поле, което уникално идентифицира стоката и програмата го използва за маркер за индивидуалната стока. Ако това поле не присъства, то програмата не може да различи една стока от друга. Ще се търсят заобиколни начини за решаване на проблема.

2. Автоматично въвеждане на сумите в каса при импорт на операции.
Отг. Ще го оправим.

3. Добавяне на стъпка при операция, за междинно запомняне състоянието на документа.
Тук статуса е неясен. В следващата версия няма да разглеждаме тази възможност, ще я оставим за следващ етап.

4. Премахване отварянето на празен прозорец след всеки импорт на операция.
Отг. Това не ни е ясно.

5. Визуализиране на колоната с кода на стоката в прозорците на операциите и в тези за редакцията на документи.
Отг. Ще го има във версия 3.01.009 (виж 2.4.)


IV. по ЦЕНОВИТЕ ГРУПИ И КАСОВИТЕ ОПЕРАЦИИ

1. Добавяне на възможност за въвеждане на доставни и продажни цени поне в една валута, които да се пазят в отделно именовани колони, подредени при ценовите колони, като валутните цени да могат да се използват както за директни операции в избраната валута така и да се конвертират в лева при избор на такъв вид работа от потребителя.
Отг. Това трябва да се анализира по-внимателно и след това ще отговорим.

2. Добавяне на възможност да се следят касовите операции в касовата книга по потребител и по партьор.
Отг. Защо в касовата книга трябва да се следи партньор? В нея могат да се добавят редова които по никакъв начин не са свързани с конкретен партньор по никакъв начин: консумативи, заплати, наеми, други разходи и т.н. Защо не използвате разплащанията? Има множество справки свързани с тях: ‘Справки->Разплащания->Плащания по партньори’, ‘Справки->Разплащания->Плащания по документи’, ‘Справки->Разплащания->Падеж на плащанията’, ‘Справки->Разплащания->Хронология на плащанията’, ‘Справки->Разплащания->Постъпления’, ‘Справки->Excel документи->Оборот по потребители’


V. по ВИЗУАЛНИ И ДИЗАЙНА:

ВИЗУАЛНО ПОГРАМАТА СТОИ ДОБРЕ.

Забележка:Може да се помисли за въвеждане на информационен бар за налични отворени прозорци, за да бъде резидентно на информационно разположение. А и не разбирам идеята проверката на работната база да е толкова трудно достъпна, а не на инфо-лентата.
Отг. Подобна идея има още от начало на разработката на програма, но тя за момента със сравнително нисък приоритет. Принципно при нормална работа никога не се налага да се проверява базата от данни, винаги се работи с текущата база и информационния базр ще има други задачи.
Върнете се в началото
Вижте профила на потребителя Изпратете лично съобщение Изпрати мейла Посетете сайта на потребителя
dobronameren



Регистриран на: 05 Фев 2007
Мнения: 93

МнениеПуснато на: Пон Фев 26, 2007 18:50    Заглавие: Отговорете с цитат

Благодаря за изчерпателния отговор. Сега ще върна информация само по неясните и спорни пунктове. Останалото приемам в конкретиката за начина и срока на реализация , които сте дали.

1.Премахване на грешката за загуба на привързания към потребителя обект при смяна на базата и връщане отново в предишната база.
Отг. Може ли да ни предоставите малко повече информация, как точно се получава тази ‘тази загуба на привързания към потребителя обект’!?
Пояснение: Това се получава при превключване между работни бази, когато има повече от един потребители регистрирани в база и поне един от потребителите е общ за базите, които се превключват. Пример: Потр.1 – Иван, Потр.2 – Мария. База 1 – Фирма „ Алфа”, База 2 – Фирма „Бета” . Затварям База 1, т.е. отварям База 2, потребителя в База 1 е бил Иван. В база 2 искам да е Мария, макар и Иван да е регистриран потребител там. Излиза : потребител: Мария, фирма: Бета. Връщам се отново към База 1 и искам да работя с Иван. Излиза: потребител: Служебен потребител, фирма: Алфа.
Това го демонстрирах преди 20-тина дни, мисля че беше на г-н Кадиев по дистанционния контрол. Нямаше коментар. Всичко по привързването на потр. към обект и обект за рег. беше спазено,т.е. не е налице синдрома на часовниците. Решил съм си проблема като База 1 е с регистриран потр. само Иван, а База 2 с всички останали потребители, включително и Иван. Няма проблем и ме устройва, но просто вие си сверете този път часовниците.


2.Забележка: Неясно защо, програмата държи настройка за размера и включването на ДДС-то в цената на стоката, различна от тази на потребителите, т.е реципрочна. Не пречи при работата, но е смущаващо.
Пояснение: Така е, разминаването не е между настройката на потребител и програма, а между база и програма. Не пречи, но е малко нелогично след като настройката за ДДС се отнася към определана база, програмата като цяло също да държи определена настройка и тя да влиза в противоречие с тези бази, които са настроени по обратния начин за следене на ДДС.

3.Добавяне на колона с количествата в таблицата с намерените стоки в "локатор".
Отг. Може да бъде направено. Доста неясно ще е за количествата в кой обект става дума, но принципно може да се направи.
Пояснение: Да, вероятно е неясно и защо ще му е на някой тази наличност. Ще ви запозная ако проявите желание. Иначе стандатно след като се работи с локатора, там трябва да се виждат наличните количества общо за фирмата във всички обекти.
Ново:Добре би било да се добави информационен бар в прозорците за операции, където да се виждат наличните количества в обекта, когато стоите върху съответния ред в документа. Защо? Причини няколко, но напр. опитните търговци или тези, които работят направо с код на стоката или пък с баркод четец, не минават през таблицата със стоките, където могат да видят наличността. Това, че като продават повече отколкото имат ще им светне в червено, не е достатъчно. В много случаи се налага при въвеждане на самата продажба, отпускане на исканото количество и реализиране на някаква отстъпка, търговецът да се съобрази с наличното количество, а за това е необходимо отново да се върне и да влезе в таблицата със стоките.


4.Добавяне на възможност за заместване на данни в колоните с наименованието, каталожните номера, баркодовете, както и в ценовите колони, по следната схема: редакция / заместване на данни - прозорец тип "импорт"; позициите, които се обработват се идентифицират по кода на стоката (тази колона не може да се замества), останалите колони се обработват само при наличие на данни, т.е. при посочване на N на колона от файла за импорт на заместващи данни.
Отг. Няма лесен начин да бъде реализирано! Винаги има едно поле, което уникално идентифицира стоката и програмата го използва за маркер за индивидуалната стока. Ако това поле не присъства, то програмата не може да различи една стока от друга. Ще се търсят заобиколни начини за решаване на проблема.
Пояснение: Вижте какво съм написал по-горе: „позициите, които се обработват се идентифицират по кода на стоката (тази колона не може да се замества)”. Нали така се обработват и документите за доставка например - аз въвеждам само код и стоката се идентифицира еднозначно, а продажната цена се замества директно при въвеждането и при тази операция. Това заместване не може да не е приложимо и за всичко останало – каталожни номера, баркодове, ценови групи и т.н., по същата уникална идентификация – т.е. по кода., само трябва да бъде създадена такава функция – редакция на стоки със заместване или : редакция/стоки/заместване и документа да съдържа колоните от таблицата на стоките, като импортвайки в него да идентифицираме стоките по кода, а колоните с катал.N и ценовите листи се прочитат от импортния файл спрямо тях. Не разбирам къде е проблема.

5.Добавяне на стъпка при операция, за междинно запомняне състоянието на документа.
Отг.:Тук статуса е неясен. В следващата версия няма да разглеждаме тази възможност, ще я оставим за следващ етап.
Пояснение: Вероятно се чудите какви да са тези документи, които ще бъдат започнати и недовършени. Просто пускате една нова позиция: операции/и там някъде или в мениджънт – „прилкючване на операции” ви отваря списък с неприключените документи, т.е тези , които са съхранени във формат за отваряне и корекция, но не са повлияли на наличностите и цените (независимо висящи документи). Там имаме бутони: „редакция” и „приключване”. Когато редакцията на документа е окончателна, с натискане на бутон „приключване”, маркирания в списъка с неприключените документи, се приключва, той излиза от този списък и заминава по веригата на F9. Как този документ попада в списъка на неприключените? Натискането на F9 си остава за всички, които не желаят да свикват с нововъведения.Ако обаче натиснете Х или искате да напуснете базата или програмата, получавате прозорец: желаете ли изход без съхранение на операцията? Ако натиснете да – става това, което знаем. Ако натиснете „не”, тогава идва новото съобщение: Операцията ще бъде съхранена като неприключена. Натискате „ок” и готово. Държа да коментираме тази тема.

6.Премахване отварянето на празен прозорец след всеки импорт на операция.
Отг. Това не ни е ясно.
Пояснение: След всеки импорт на операция остава един празен отворен прозорец с наименованието на операцията.Пример: Ако импортирам 10 доставки, след приключването на съхранението им с F9, на екрана имам 10 отворени прозореца „доставка”, които 10 пъти трябва да Х-на.

7.Добавяне на възможност да се следят касовите операции в касовата книга по потребител и по партьор.
Отг. Защо в касовата книга трябва да се следи партньор? В нея могат да се добавят редова които по никакъв начин не са свързани с конкретен партньор по никакъв начин
Пояснение: Да, но има и такива допълнителни приходи и разходи, които без да минават през операции, касаят дирекно касовите операции: други приходи и разходи и са отнесени към конкретни потребители. А що се касае за потребителя, от всички скл.програми които съм виждал и с които съм работил, тази е първата с касова книга, в която не е видно кой вкарва и изкарва пари от касата. Моля ви – смешно е.Тази тема също ще се дискутира сериозно.

8.Забележка:Може да се помисли за въвеждане на информационен бар за налични отворени прозорци, за да бъде резидентно на информационно разположение. А и не разбирам идеята проверката на работната база да е толкова трудно достъпна, а не на инфо-лентата.
Отг. Подобна идея има още от начало на разработката на програма, но тя за момента със сравнително нисък приоритет. Принципно при нормална работа никога не се налага да се проверява базата от данни, винаги се работи с текущата база и информационния базр ще има други задачи.
Пояснение: Опревержение на вашия отговор се вижда в оплакването на ваш клиент от тези дни, който всяка сутрин тичал да настройва базите, понеже операторите не отварат менюто, откъдето да погледнат, а информация на екрана липсва и те си чукат „ентер”-и до дупка. Вижте, когато работите с две или повече фирми и сте принуден цял ден да превключвате базите, защото някой така е измислил програмата, нормално е в 16ч. следобед да забравите кое поредно превключване сте направил и непрекъснато ви се налага да отваряте менюто за да се информирате. Това е все едно, когато ви се наложи да си погледнете часовника, да имате на ръката екранче с бутончета и меню, с което да стигнете до жадуваната информация : колко е часа.
Вярвайте на потребителите – те знаят какво им трябва. Това, че вашите програмисти знаят как да направят нещо, не значи, че са го измислили така, че да е удобно на потребителите. Очаквам отговори по направените от мен пояснения и се надявам схемата, по която мисля че започнахме добре да работим, да даде добри резултати за всички.
Успешна работа!
Върнете се в началото
Вижте профила на потребителя Изпратете лично съобщение Изпрати мейла
Виктор Павлов
Microinvest
Microinvest


Регистриран на: 12 Авг 2002
Мнения: 21077

МнениеПуснато на: Пон Фев 26, 2007 18:58    Заглавие: Отговорете с цитат

Нека следващите коментари да бъдат след новата версия. Иначе ние продължаваме да работим по поставените въпроси.
Върнете се в началото
Вижте профила на потребителя Изпратете лично съобщение Изпрати мейла Посетете сайта на потребителя
dobronameren



Регистриран на: 05 Фев 2007
Мнения: 93

МнениеПуснато на: Сря Фев 28, 2007 18:58    Заглавие: Отговорете с цитат

Да не забравя да допълня и включването на "описание" в колоните, които могат да се експортират от справки. Наложително е за оферти и заявки.
Върнете се в началото
Вижте профила на потребителя Изпратете лично съобщение Изпрати мейла
Покажи мнения от преди:   
Създайте нова тема   Напишете отговор    Microinvest Форум Форуми -> Предложения All times are EET (Източна Европа)
Страница 1 от 1

 
Идете на:  
Не Можете да пускате нови теми
Не Можете да отговаряте на темите
Не Можете да променяте съобщенията си
Не Можете да изтривате съобщенията си
Не Можете да гласувате в анкети


Powered by phpBB © 2001, 2005 phpBB Group
Translation by: Boby Dimitrov