Пользователи очень хотят чтобы в Аналитических счетах в Книге операций по аналит. счетам можно было выводить отчет по счету( например 6015) по всем контрагентам в Excel. Сейчас это можно только если указать одного контрагента, а по всем контрагентам отчет выдается только в Word.
Сделайте , пожалуйста.
И еще нужно сделать функцию отлова нулевых записей в main, и других базах чтобы не возникали ребусы БЭСТа которые приходится разгадывать очень часто . Не далее как сегодня была проблема суть которой в следующем.
Кассир вводила выписку за 6 и 7 июня ( по 14 листов каждая) . Выписка за 6 июня показывает неправильный итог по приходу ( там где ИТОГО оборотов )не суммируется одна из строк, если нажать F9 и вывести выписку в Excel то если просуммировать столбец по приходу , то сумма правильная ( т.е с учетом той строки , которая не учитывается в Итого оборотов в самом БЭСТе). В результате архиологических раскопок выясняется что при вводе выписок за 7 июня введена запись у которой заполнена только дата 06/07/05 .т.е за 7 июня, а далее все пусто , пустая строка.
И этож надо догадаться что из-за этого не идет сумма выписки за 6 июня!!!. После удаления вышеуказанной строки , все стало на свои места. Это не первая ситуация с выписками .
Нужно поставить предупреждение о существовании пустых записей .
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 08 Jun 2005 19:22 Post subject:
Ой-хой!.. Пожелание-то хорошее, вот только ответят на него, как и мне: "С такими претензиями не сталкивались"... _________________ С уважением, Олег Р. Смирн
Надо бы завести постоянную тему для мелких хотелок, для которых нет смысла заводить отдельную тему, и повесить ее всегда на первой странице как объявления.
Это было бы хорошо. Есть ведь раздел ОБЪЯВЛЕНИЯ , такой -же нужно создать для хотелок ( ну или назовите это как вам понравится), и пользователи и те кто на них работает помещали бы туда свои предложения и желания. Понятно что не все желания исполняются. Но вдруг однажды утром проснувшись тот же Титов ( Астахова или еще кто-нибудь) подумал бы.
" У меня сегодня отличное настроение, а не поделиться ли мне им с ..... "
И выбрал бы себе город или человека для которого он сегодня хочет сделать доброе дело. Ведь он понимает что сделав добро одному , он делает добро многим и прежде всего делает добро себе.
А мы бы его за это больше зауважали
Эта тема очень важная. Почему- то именно БЭСТ4+ стала чувствительной к появлению "пустых" записей.
За последние 3 месяца я несколько раз столкнулся с этой проблемой. Если файл содержит менее 65000 записей - то открываю его в Excel, по фильтру нахожу пустые, а затем корректирую средствами БЭСТ или BDBFSили FOX.
Необходимо поставить АВТОМАТИЧЕСКОЕ удаление пустых записей при ИНДЕКСИРОВАНИИ. Или сделать отдельный пункт ВОССТАНОВЛЕНИЕ БД.
Еще сложнее решаются проблемы с FPT. Недавно замучился с КНИГОЙ ПРОДАЖ. При закрытии периода - фатальная ошибка... Если прорамма обнаружила ошибку, значит надо на нее указать хотя бы в режиме КОНТРОЛЬ и ВОССТАНОВЛЕНИЕ ДАННЫХ в соответствующем блоке. Так как найти ошибку в FPT не знаю как, был вынужден в BDBFS удалить (на копии) половину и проверить закрытие на оставшейся. И наоборот. И так далее, пока не определил, что надо выбрасывать.
Joined: 26 Jul 2002 Posts: 975 Location: Титов Александр Александрович Occupation: Компания БЭСТ Interests: Москва
Posted: 10 Jun 2005 16:14 Post subject:
Александр wrote:
Эта тема очень важная. Почему- то именно БЭСТ4+ стала чувствительной к появлению "пустых" записей.
За последние 3 месяца я несколько раз столкнулся с этой проблемой. Если файл содержит менее 65000 записей - то открываю его в Excel, по фильтру нахожу пустые, а затем корректирую средствами БЭСТ или BDBFSили FOX.
Необходимо поставить АВТОМАТИЧЕСКОЕ удаление пустых записей при ИНДЕКСИРОВАНИИ. Или сделать отдельный пункт ВОССТАНОВЛЕНИЕ БД.
Еще сложнее решаются проблемы с FPT. Недавно замучился с КНИГОЙ ПРОДАЖ. При закрытии периода - фатальная ошибка... Если прорамма обнаружила ошибку, значит надо на нее указать хотя бы в режиме КОНТРОЛЬ и ВОССТАНОВЛЕНИЕ ДАННЫХ в соответствующем блоке. Так как найти ошибку в FPT не знаю как, был вынужден в BDBFS удалить (на копии) половину и проверить закрытие на оставшейся. И наоборот. И так далее, пока не определил, что надо выбрасывать.
ДАЕШЬ проверку на пустые записи и файлов FPT !!!
Ok! Что-нибудь придумаем _________________ С уважением, Александр Титов, Компания БЭСТ, Москва, отдел разрабо
Posted: 14 Jun 2005 19:35 Post subject: Re: Пожелания
DI wrote:
ДОБРОГО ВРЕМЕНИ СУТОК , ВСЕМ ЧИТАЮЩИМ!
Пользователи очень хотят чтобы в Аналитических счетах в Книге операций по аналит. счетам можно было выводить отчет по счету( например 6015) по всем контрагентам в Excel. Сейчас это можно только если указать одного контрагента, а по всем контрагентам отчет выдается только в Word.
Программа viewer32 выдает в Excel любые отчеты Б4 _________________ http://v32.ru - печать и экспорт в Excel отчетов БЕСТ4.
Александр, насчет FPT-файлов присоединяюсь: у меня тоже недавно всплыли такие ошибки. Правда, в складе, а не в управлении продажами, но смысл один - в DBF-файле нарушаются ссылки на memo-поля (номер блока в FPT-файле, указанный в записи в DBF, не пуст, но указывает не на начало memo-поля, а на середину). Пока написал программку на FoxPro, которой и подчищаю это - она просто читает DBF- и FPT- файлы на низком уровне и подставляет в memo-поле пустую строку там, где найдет неправильную ссылку. Если интересно, могу ее тебе выслать, а ты доработаешь до своих нужд. Хотя, если Александр Титов пообещал что-то придумать, может, лучше и подождать.
Для ИС: ведь можно отказаться от этих FPT и записывать строки неопределённой длины (коменты, списки складов, печатные формы и т.п.) в специальную DBF базу вида:
COD_SSYLKA (С6) - код-ссылка
CHAST (Cxxx) - порядковый номер части текста.
Если это xxx=1 (1 символ), то можно использовать символы начиная с кода 32 по символ 126 (цифры, симолы и англ. алфавит). Итого 95 частей.
Если xxx=2 и более - то вариантов куча - от десятичных чисел, до HEX кодов.
TEXT (Czzz) - кусок текста.
Длина от, например, 10 (меньше смысла нет) до 255 символов. Оптимальную длину можно определить статистическим методом.
А можно эту длину задавать как параметр БЭСТ. Кто как хочет, так и задаст.
Функции "сборки"/"разборки" строки на части элементарны.
И ИМХО будет меньше сбоев.
И Excel и Access не умеют нынче читать FPT-поля.
В продолжение темы: в BMOD/CMOD-версии в настройке предприятия была (и есть) функция упаковки .fpt-файлов, а в BIN-версии нет. Может, все-таки ее вернуть?
Это пожелание возникло не столько из-за длины fpt-файлов, сколько из-за того, что Harbour стремится писать memo-поля новых записей не в конец файла, а на место, где были поля достаточной длины от старых записей, которых давно нет, а fpt упакован не был. Наверно, это происходит не всегда, но при определенных условиях, не знаю каких. Из-за этого иногда бывают сбои типа "ошибка DBFCDX/1012". Команда FoxPro pack memo тоже вылетает. Есть, конечно, обходной путь (с помощью того же FoxPro), но если где-то своего программиста нет, кому этим заниматься?
2 Krosh: идея хорошая, но, IMHO, кое-что в ней придется доработать:
1. memo-поля бывают не только строковые, но и массивы. Примеры: pro\plugins\ppo.dbf с .fpt (fileeval-ы), *vdoc.dbf с .fpt (шаблоны документов). С ними явно придется работать по-другому.
2. Код-ссылка 6 байт... ну, Вы тут определенно "считали не как спартанец, а как прокурор" ( (c) А.Дюма-отец устами д'Артаньяна). И дело даже не в длине поля, а в том, что в него писать. Если физический номер записи, то это усложнит процедуры индексации с упаковкой и закрытия периода во всех АРМ. Если значение ключа (такое, как в индексном файле), то как делать универсальный вариант? Или придется генерировать уникальные коды типа guid?
Joined: 26 Jul 2002 Posts: 975 Location: Титов Александр Александрович Occupation: Компания БЭСТ Interests: Москва
Posted: 22 Jun 2005 08:59 Post subject:
Квазимодо wrote:
В продолжение темы: в BMOD/CMOD-версии в настройке предприятия была (и есть) функция упаковки .fpt-файлов, а в BIN-версии нет. Может, все-таки ее вернуть?
Это пожелание возникло не столько из-за длины fpt-файлов, сколько из-за того, что Harbour стремится писать memo-поля новых записей не в конец файла, а на место, где были поля достаточной длины от старых записей, которых давно нет, а fpt упакован не был. Наверно, это происходит не всегда, но при определенных условиях, не знаю каких. Из-за этого иногда бывают сбои типа "ошибка DBFCDX/1012". Команда FoxPro pack memo тоже вылетает. Есть, конечно, обходной путь (с помощью того же FoxPro), но если где-то своего программиста нет, кому этим заниматься?
Доброе утро!
Да, этот режим будет вновь введен в 12 версии. _________________ С уважением, Александр Титов, Компания БЭСТ, Москва, отдел разрабо
Joined: 13 Oct 2003 Posts: 97 Location: КИА Occupation: СТ Interests: Москва
Posted: 22 Jun 2005 09:45 Post subject:
Квазимодо wrote:
2 Krosh: идея хорошая, но, IMHO, кое-что в ней придется доработать:
1. memo-поля бывают не только строковые, но и массивы. Примеры: pro\plugins\ppo.dbf с .fpt (fileeval-ы), *vdoc.dbf с .fpt (шаблоны документов). С ними явно придется работать по-другому.
memo-поля бывают ТОЛЬКО строковые. А вот содержимое строки - может представлять из себя запись массива в строку.
Вообще-то запись массива в FPT-файл
в Clipper это просто присвоение (типа FIELD->MY_FIELD = MyArray) или "извлечение" (MyArray = FIELD->MY_FIELD)
при которых в "фоновом" режиме происходит преобразование массива в СТРОКУ и наоборот. Это достаточно просто для ЛЮБОГО программера (если полениться и не найти готовую ф-цию).
Квазимодо wrote:
2. Код-ссылка 6 байт... ну, Вы тут определенно "считали не как спартанец, а как прокурор" ( (c) А.Дюма-отец устами д'Артаньяна).
И дело даже не в длине поля, а в том, что в него писать. Если физический номер записи, то это усложнит процедуры индексации с упаковкой и закрытия периода во всех АРМ. Если значение ключа (такое, как в индексном файле), то как делать универсальный вариант? Или придется генерировать уникальные коды типа guid?
Ну 6 - это для примера. Можно столько, сколько нужно.
Мне например хватает 6 цифр, т.е. можно закодировать 1 млн. записей.
Если использовать цифры+буквы - вообще немеряно. Хотя для "красоты" лучше использовать цифры + большие английские буквы. Это даёт 10+25=36 символов в одном знакоместе. Итого - 36 в степени 6 возможных записей (строк). Этого более чем достаточно, ИМХО.
Писать ФИЗИЧЕСКИЕ номера в этот код КАТЕГОРИЧЕСКИ нельзя. Физические номера записей вообще никогда нельзя использовать для ключа-связки. У нас, например, для "лечения" DBF приходиться создавать новую базу с содержимым старой, при этом физическая последовательность меняется.
Значение индексного ключа - это не универсально, т.к. эти ключи разные в разных местах.
Лучше всего "уникальные коды типа guid". И формировать этот код, также как и остальные нумераторы, по БД, а не переменной, как сейчас в БЭСТ.
Вроде пишут что нумераторы будут переделаны, узнать бы заранее как именно.
Ещё можно расширить "рекламируемый" мной алгоритм так:
COD_SSYLKA (Сnnnnnnnnnn) - код-ссылка
TYPE_FIELD (Cmmmmm) - код поля.
CHAST (Cxxx) - порядковый номер части текста.
TEXT (Czzz) - кусок текста.
Код поля - это указание значение какого именно поля сохраняется в данном DBF.
В таком виде можно иметь и достаточно легко обслуживать один DBF со строками для всех или для каждого из модулей БЭСТ, для всех БД или для конкретной БД.
Krosh, спасибо за разъяснения. Действительно, я тут прилично натупил, практически обозвав ВСЕ записи в .fpt-файле memo-полями, хотя в описании структуры этих файлов сказано:
Quote:
Record type
00h Picture
01h Memo
02h Object
Вот именно в записях picture и хранятся откомпилированные (точнее, разобранные до операторов) вставки кода в шаблоны документов или fileeval-ы. Так что их можно было бы хранить по Вашему алгоритму. Кстати, у меня тоже недавно был случай - проапгрейдили одну из баз до BIN (11.03), и пошли вылеты и подвисания на запись документов (удаленный склад) и на функции по требованию. Оказалось, что в ppo.dbf нарушились ссылки на ppo.fpt. Мелочь (судя по тому, что надо было сделать для лечения - выгнать всех из БЭСТа, заменить все поля file_eval на пустые, а при следующем входе они перекомпилировались), а не очень приятно.
Насчет уникальных кодов - тоже было бы неплохо, особенно в свете наболевшей темы про нумераторы в отдельной таблице. Но все это, наверное, в перспективе более долгой, чем то, о чем я упоминал в предыдущем посте (упаковка fpt-файлов)...
Joined: 26 Jul 2002 Posts: 975 Location: Титов Александр Александрович Occupation: Компания БЭСТ Interests: Москва
Posted: 23 Jun 2005 09:20 Post subject:
Krosh wrote:
Вроде пишут что нумераторы будут переделаны, узнать бы заранее как именно.
Добрый день!
По поводу нумераторов. Нумераторы остаются целыми числами, младшая часть формируется также как и формировалась раньше - по возрастанию, только ее разрядность составляет 10 цифр вместо 7. К младшей части слева пришлепывается старшая часть - случайное число в интервале от 0 до 9999. Длина поля составляет 17 цифр. Три левых разряда не используются.
Насчет FPT - полей. Спасибо, подумаем. Кстати, в ранних версиях в движке была ошибка при работе с FPT полями, которая могла в определенных ситуациях приводить к сбоям, в текущей версии она исправлена. _________________ С уважением, Александр Титов, Компания БЭСТ, Москва, отдел разрабо
All times are GMT + 4 Hours Goto page 1, 2, 3, 4, 5, 6Next
Page 1 of 6
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
.gif)
или перейдем на другие программы....
