Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 26 Jan 2005 14:27 Post subject: Вопрос про NNOPER в main.dbf или перехлест проводок-6 (+)
Скажите пожалуйста, знатоки БЭСТ-4, должны ли в файле main.dbf значение в поле NNOPER быть уникальным при условии разного значения в поле NNDOC, т.е. если мы имеем одинаковые значения NNOPER, то обязательно должны быть одинаковыми и NNDOC? Все это для того, чтобы хоть как-то попытаться объективно найти "перехлестнутые" проводки...если бы удалось установить формальные признаки таковых, то написать внешнюю прогу для поиска этих проводок в пределах заданного периода пара раз плюнуть, а это самое важное на данный момент.
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 26 Jan 2005 16:38 Post subject: Re: Вопрос про NNOPER в main.dbf или перехлест проводок-6 (+
Svarog wrote:
Скажите пожалуйста, знатоки БЭСТ-4, должны ли в файле main.dbf значение в поле NNOPER быть уникальным при условии разного значения в поле NNDOC
Теоретически - должны, но! теоретически и неуникальных номеров группы порождённых проводок быть не должно. Так что пиши прогу, только исправлять из неё ничего не рекомендую - пусть выдаёт данные о сомнительных проводках/документах, а рабираться потом всёравно человеку... _________________ С уважением, Олег Р. Смирн
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 26 Jan 2005 17:08 Post subject:
Насчет неуникальных групп - я тут посмотрел фрагмент файла main.dbf на предмет повторения nnoper - обычное дело. Например, НДС имеет тот же автономер (и номер естественно), что и основная проводка, и это нормально. Еще больше порождает записей с дублированным nnoper документ из Зарплаты - я до 6 штук насчитал, все с одними номерами и автономерами, по Наименованию операции ясно что сие есть.
Рекомендованная разработчиками проверка автономеров из АРМа главного бухгалтера, похоже, вытаскивает только самые верхи.
Я вот думаю, что наверное еще более актуально при дублировании nnoper проверить поле task - если оно разное, то кирдык, пошел явный перехлес
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 26 Jan 2005 17:23 Post subject:
Svarog wrote:
Насчет неуникальных групп - я тут посмотрел фрагмент файла main.dbf на предмет повторения nnoper - обычное дело. Например, НДС имеет тот же автономер (и номер естественно), что и основная проводка, и это нормально.
А я же и написал: "неуникальных номеров группы порождённых проводок быть не должно" И нигде не писал, что в группе проводок может быть только одна проводка...
Svarog wrote:
Я вот думаю, что наверное еще более актуально при дублировании nnoper проверить поле task - если оно разное, то кирдык, пошел явный перехлест.
Оно конечно так, а что делать, если перехлёст из одного АРМа?!. И кто поручится, что пресловутый перехлёст происходит только из разных АРМов? _________________ С уважением, Олег Р. Смирн
Как известно, история со смежными проводками очень старая, но актуальна и поныне.
Года 2 назад для одного клиента (было в тот момент 12 компьютеров, сейчас 42 с сервером под WIN 2000) я был вынужден сделать программу для поиска смежных документов. Эта программы используется и сейчас. Поиск средствами БЭСТ не дает 100% результата.
В этой фирме 2 основные БД. Одна закрывается в складе ежемесячно, т.а объем склада увеличивается за месяц до 700 Mб.
Другая к концу года достигает 1-1.2 Гб
Запускаю программу перед закрытием периода в складе или по просьбе.
Обычно за месяц наблюдается до 30 пар смежных документов по складу, до 10 смежныхх кассовых со складскими, до 5 смежных кассовых документов. (работает в среднем 30-40 рабочих мест, чило накладных около 20000 в месяц)
Программа сделана в VBA над Excel с использованием MS Query (для скорости). Прооверяются сочетания "СКЛАД-СКЛАД", "КАССА-СКЛАД", "КАССА-КАССА", "БАНК-СКЛАД". Остальные сочетания не проверяю -маловероятны (хотя были).
Для проверки в одном блоке - выбираете спиок документов (например, MDOC.DBF, сортироете по полю с номером операции, и дольше попарно сравниваете. два разных документа не должны иметь один номер операции. Их и выделяете в список парных документов.
Если число документов не более 65000, то можете скопировать MDOC.DBF , затем открыть в Excel, отсортировать как сказано, и найти пары рядом стоящие.
Если больше, то пишите программу.
Я когда - то писал в ИС, что не бывает одинаковых номеров накладных, так что мешает также отдать НОМЕР операции документу сразу при его создании, даже если документ не будет сохранен. И сразу записать этот номер в общий для всех файл.
Кстати, проблема, по моему есть только в сочетании Win 2000 + Win98 (станции). Я никогда не наблюдал эту проблему на NW+ Win98 и на WIN98 + Win98. Правда там обычно нет такой интенсивности. Но наблюдал ее даже на 7 раб. местах с сервером Win 2000, где рабоатет активно буквально 2 операто
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 26 Jan 2005 21:02 Post subject:
Мне вот тут вспомнилось, что когда-то давно (лет 10 назад ) были такие данные, что TCP/IP как-то не очень то подходит для блокирования записей при сетевой работе (равно как и NetBEUI). В этом аспекте оченно интересно, а бывают ли косяки с nnoper там, где сервер Win2000 и протокол IPX? _________________ С уважением, Олег Р. Смирн
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 26 Jan 2005 23:49 Post subject:
Quote:
Мне вот тут вспомнилось, что когда-то давно (лет 10 назад ) были такие данные, что TCP/IP как-то не очень то подходит для блокирования записей при сетевой работе (равно как и NetBEUI). В этом аспекте оченно интересно, а бывают ли косяки с nnoper там, где сервер Win2000 и протокол IPX?
К сожалению не успел этого проверить, т.к. больше года назад перевел базы БЭСТа с сервера W2KS на Linux/SAMBA, а там IPX нет в принципе. Историю про то, что БЭСТ-4 изначально заточен под IPX и плохо работает со всеми остальными транспортами слышал во многих вариантах, дошел даже то того, что снес на сервере W2KS все протоколы кроме IPX - но тогда для меня критичным были тормоза и постоянные подвешивания баз юзерами, не успел установить, влияет ли это на "перехлест" проводок. На скорость точно не влияло...
Но сейчас точно буду переходить на NW5.1 - к чертовой бабушке весь этот НИОКР, мне других проблем хватает кроме БЭСТа...
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 27 Jan 2005 00:11 Post subject:
Quote:
Программа сделана в VBA над Excel с использованием MS Query (для скорости). Прооверяются сочетания "СКЛАД-СКЛАД", "КАССА-СКЛАД", "КАССА-КАССА", "БАНК-СКЛАД". Остальные сочетания не проверяю -маловероятны (хотя были).
Т.е. для сочетания СКЛАД-СКЛАД проверяется на предмет дублирования nnoper файл scald\mdoc.dbf, а для сочетания БАНК-СКЛАД - файлы bank\mdoc.dbf и sclad\mdoc.dbf? Для тупого варианта с Excel'ом эти файлы открываются в разных окнах, а потом сливаются и сортируются по полю nnoper? А как исключаются проводки в одной группе, по определению имеющие одинаковый nnoper - по одинаковому полю ndoc?
Вообще мысль глубокая - анализировать не main.dbf, а исходные файлы на предмет перехлеста проводок. С перекрестными перехлестами (в разных АРМах) все вроде ясно - там дублирования nnoper быть просто не должно, а вот как с пересечениями в одном АРМе - исключать ли их по номеру документа или тут еще есть сокровенное знание?
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 27 Jan 2005 07:31 Post subject:
Svarog wrote:
Вообще мысль глубокая - анализировать не main.dbf, а исходные файлы на предмет перехлеста проводок. С перекрестными перехлестами (в разных АРМах) все вроде ясно - там дублирования nnoper быть просто не должно, а вот как с пересечениями в одном АРМе - исключать ли их по номеру документа или тут еще есть сокровенное знание?
Данная мысль глубока по одной простой причине: в main.dbf, как ты и сам верно подметил, одинаковый номер у группы проводок, и поди разберись - на самом ли деле эти проводки - одна группа, или что-то ещё затесалось? А вот что касается первичных документов (тех, что порождают проводки) - там всё ясно - на один документ (одна запись в базе с заголовками документов) - одна группа порождённых проводок. Т.е., если ты в файле mdoc.dbf обнаружил две или более записей, у которых в поле mdoc.pro стоит одинаковый номер, и это не 0 - congratulations! - ты нашёл перехлёст.
P.S. Кстати, перехлёст такого типа ты в main.dbf и вообще никогда не найдёшь - при генерации проводок сначала запишутся проводки для одного документа, потом, поверх, запишутся проводки другого с тем-же номером mdoc.pro - вуаля! - нет никаких перхлёстов, и проводок по одному из документов тоже - тю-тю... _________________ С уважением, Олег Р. Смирн
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 27 Jan 2005 09:53 Post subject:
Как искать перехлеснутые проводки в принципе стало ясно ))))
Еще бы И-С, раз уж не может ликвидировать эту проблему в краткосрочной перспективе, написал бы отчет, позволяющий эту проблему корректно локализовать. Или внешнюю утилиту с той же целью...
Joined: 26 Jul 2002 Posts: 975 Location: Титов Александр Александрович Occupation: Компания БЭСТ Interests: Москва
Posted: 27 Jan 2005 11:58 Post subject:
Svarog wrote:
Как искать перехлеснутые проводки в принципе стало ясно ))))
Еще бы И-С, раз уж не может ликвидировать эту проблему в краткосрочной перспективе, написал бы отчет, позволяющий эту проблему корректно локализовать. Или внешнюю утилиту с той же целью...
Мы уже много писали об этом:
Вы можете выполнить тестирование счетчиков проводок командой:
BMOD\nsldr.exe BMOD\INIT.EXE TEST. Тестирование нужно выполнять с нескольких рабочих станций.
Вместо BMOD можно писать CMOD или XMOD.
Нужно запустить с максимально возможного количества рабочих станций (со всех).
Тестирование нужно произвести один раз при положительном результате. Если результат будет отрицательным, необходимо решить сетевые проблемы и запустить повторно.
Суть теста сводится к проверке блокировки файлов на сервере.
Для контроля можно использовать отчет:
1 Арм главного Бухгалтера
2 Ведение системы счетов
3 Контроль счетов и остатков
4 Контроль системных номеров проводок
5 Поставить Да
6 Выполнить
7 В полученном отчете будут отражены все "неправильные" проводки
где первая колонка системный номер(MAIN-NNOPER)
Вторая- два кода арма где встретились одинаковые номера
третья - два номера документа -//-
четвертая даты документов -//-
Как я уже говорил, в Б4+ в течение первого квартала будет введен механизм глобальных идентификаторов, который не будет зависеть от правильности работы сетевых блокирово _________________ С уважением, Александр Титов, Компания БЭСТ, Москва, отдел разрабо
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 27 Jan 2005 12:37 Post subject:
Quote:
Мы уже много писали об этом:
Вы можете выполнить тестирование счетчиков проводок командой:
BMOD\nsldr.exe BMOD\INIT.EXE TEST. Тестирование нужно выполнять с нескольких рабочих станций.
Вместо BMOD можно писать CMOD или XMOD.
Я про это хорошо знаю и убил на эти исследования массу времени. Проблемы тут возникают две:
1. Непонятно, какие именно проблемы нужно решать при отрицательном результате теста - я 12 лет работаю с сетями Ethernet и впервые слышу о таких "специфических" требованиях к сетям. Можно продиагностировать сетевые коммуникации кабельным тестером, можно проверить наличие ошибочных пакетов на соответствующем порту, можно проверить скорость передачи данных по порту. И это по сути все...что еще нужно сделать, если все это в норме а ошибки у test.bat все равно есть? Менять все по очереди у проблемной тачки, начиная с сетевой карточки и заканчивая ОС? Меняли, проблема иногда уходила, но иногда приходила вновь через некоторое время.
Другими словами, совершенно непонятно, что именно не нравится test.bat и что нужно сделать чтобы это устойчиво устранить.
2. Я много раз пускал test.bat и нащупал множество всяких закономерностей. Например, сразу после переустановки W9x test.bat, скорее всего даст положительный результат с проблемной тачкой. Если test.bat дал отрицательный результат, в данный момент может помочь переиндексация базы. На разных базах test.bat может давать разный результат. На одной и той же тачке test.bat может дать разный результат как при последовательном выполнении, так и с разницей в несколько дней. Замена сетевой карточки может дать положительный результат, а может его не дать, причем если у кого-то карточки стандартного типа, например D-Link 538, дают стабильно положительный результат, то в другой ситуации они могут стабильно давать отрицательный результат.
Все это серьезно подрывает доверие к test.bat, а если честно, то и к БЭСТ-4 - почему эта система предъявляет какие-то особые требования к сетевым оболочкам, причем совершенно не ясно, какие именно. Причем конфигурация, удовлетворяющая этим требованиям в какой-то момент может совершенно неожиданно перестать им удовлетворять в следующий момент без явной на то причины. И что делать - запускать test.bat каждый час?
Quote:
Для контроля можно использовать отчет:
1 Арм главного Бухгалтера
2 Ведение системы счетов
3 Контроль счетов и остатков
4 Контроль системных номеров проводок
5 Поставить Да
6 Выполнить
7 В полученном отчете будут отражены все "неправильные" проводки
Пробовали мы этот тест. Что-то он ловит, но есть устойчивое мнение, что он ловит далеко не все, т.к. анализирует только main.dbf на предмет задвоения поля nnoper для разных групп проводок, а правильнее было бы анализировать попарно файлы mdoc.dbf в разных АРМах на тот же предмет. Аргументы приведены выше...
Quote:
Как я уже говорил, в Б4+ в течение первого квартала будет введен механизм глобальных идентификаторов, который не будет зависеть от правильности работы сетевых блокировок.
Это конечно радостно, но все-таки хотелось бы иметь механизм проверки таковых "неправильных" проводок, причем исчерпывающий. Дело это не такое уж сложное, на мой взгляд, а польза большая.
Joined: 17 Mar 2003 Posts: 357 Location: Гусев Сергей Александрович Occupation: Сисадм Interests: Нижний Новгород
Posted: 27 Jan 2005 12:41 Post subject:
quote]а при терминальном режиме работы в w3 возможны такие ситуации?[/quote]
Насколько я понимаю, если терминальную сессию запускать на сервере баз данных (т.е. базы БЭСТа должны открываться локально) то нет. Если терминальная сессия имеет доступ к базам данных с использованием сетевого транспорта, то д
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
Так что пиши прогу, только исправлять из неё ничего не рекомендую - пусть выдаёт данные о сомнительных проводках/документах, а рабираться потом всёравно человеку... 
) были такие данные, что TCP/IP как-то не очень то подходит для блокирования записей при сетевой работе (равно как и NetBEUI). В этом аспекте оченно интересно, а бывают ли косяки с nnoper там, где сервер Win2000 и протокол IPX?
