Форум

У нас была подобная ситуация не так давно.

Цитата
Дмитрий Карпухин пишет: Поставьте в карточках СПИ, стоимость, метод, амортизационную книгу и галочку "амортизируется".

Оказывается этого не достаточно. Помимо этого, необходимо, чтобы в карточке в истории изменений ("Движение" - "История изменений") обязательно присутствовал параметр АМОРТ_НАЧ и имел значение ДА. Без этого амортизация начисляться не будет.
Этот параметр, как правило, добавляется документом ввода в эксплуатацию, но иногда (не понятно почему) не появляется.

Также интересует данный .
Будут ли какие-нибудь доработки, или, хотя-бы, методические рекомендации?
Если да, то когда?
Фактически осталась неделя на расчет зарплаты, а бухгалтера хотят провести данные изменения этим годом.

Цитата
Сергей Павличенко пишет: На передачу картинки влияет тип протокола, используемого для соединения RDP5, RDP6, RDP7, влияют параметры разрешения и цветности, выставленные в сеансе, соответственно и видеокарта.

На сервере установлен Win Server 2008. На рабочих станциях Win 7.
Пробовали со штатным RDP из Win 7 и с RDP версии 5.2.
Разрешение 1280х1024, полный экран.
В RDP версии 5.2 ставили даже 256 цветов.
Разницы практически нет, тормозит при любых настройках.

Цитата
Сергей Павличенко пишет: Это легко увидеть, если Вы зайдете в тот же сеанс с другого компьютера....

В том то и дело, что если зайти в этот же сеанс даже с этого компьютера, то тормозить перестает, пока не выйдешь и заново зайдешь в реестр (этот реестр или другой не важно, главное чтобы он был старого вида, как в БЭСТ-4). Причем в реестрах новых модулей, например "Книга покупок-продаж" такой проблемы нет.
Так что проблема, похоже, в отрисовке реестров и документов старых модулей. Что-то происходит в момент входа в эти реестры, из-за чего, в последствии, и происходит притормаживание.

Цитата
Сергей Павличенко пишет: Давайте через teamviwer посмотрим проблему, настройки и попробуем разобраться с этой ситуацией.

Давайте.
Только я в офисе бываю не часто и не долго.
Каким образом мне дать знать что в данным момент можно попробовать?

Добрый день, уважаемые разработчики!

Столкнулись с такой же проблемой. Перевели БЭСТ 5 3.4 в терминал.
Одновременно на сервере работает не более 10 человек. Почти у всех 2-х ядерные целероны свыше 2Гц, Бэст 5 у них работает нормально (по сравнению с тем что было, когда стояли клиентские рабочие места, так вообще идеально).

Но у 2-х пользователей стоят миниблоки на процессорах Atom 1.6 Гц, 2 Гб оперативки. Вот у них во всех реестрах старых модулей слайдшоу. Причем, до такой степени, что работать по сети через клиентское рабочее место намного комфортней, чем в терминале.
Воспроизводится и ситуация с отключением терминальной сессии при нахождении в реестре - при повторном подключении все летает, но стоит выйти из этого реестра и опять зайти, опять слайдшоу.
Все остальные программы, кроме БЭСТ5, на этих компьютерах в терминале работают на 5+.

Подскажите, пожалуйста, что можно сделать. Машинки эти новые (им нет еще и пол года), никто менять их не согласится. Так что надо решать проблему, тем более, что она проявляется только в БЭСТ.

Цитата
nordk пишет: В Вашем случае надо просто для себя решать каким значением должно заполняться поле NNOPER. Если не изменяет память в ранних темах на форуме этот уже обсуждался.

Для БЭСТ-4+ нашел обсуждение функций: IncStep(), Next() и StepPlus().
А для БЭСТ-5 только упоминание, что есть функция xguid().
Какая из них подойдет в данном случае?
В принципе, думаю, без разницы чем будет заполняться поле NNOPER, главное, насколькол я понял, чтобы для каждого документа значение было уникальным.

Спасибо большое.

1. Правильно я понял, сам класс (код из первого Вашего сообщения) уже встроен, и в код плагина его включать не надо?

2. Совсем не понял зачем это:
METHOD Init() CLASS CashOrder
//altd()
AbsClass():init()
::cTempFile:=TEMPFILE(m->B6_TMP_PATH,"xml")
::cTask:="01"
::cIdSubsystemActiveForm:='{E71A1FA8-C649-4D58-B845-CD4EEEA1F9A3}'
::cIDStartNodeActiveForm:='{9647E231-455D-4EA6-A9EB-3A1703AC2613}'
::cBlock:="{|| CrtRun ('Cash','Regist',,'"+::cTempFile+"')}"
RETURN self

3. И еще что значат записи типа: oCashOrder:NNOper:=(cAlias)->Pay_Oper
что такое (cAlias) и откуда он берется?

Здраствуйте.
Cуть проблемы следущая: существует DBF файл, подготовленный сторонней программой, в котором ежедневно накапливаются, по сути, кассовые документы. Так как таких документов за день минимум сотня, то решили настроить импорт из этого файла в БЭСТ-5 в модуль "Касса. Подотчеты". Функции по открытию и работе с файлами в документации в принципе описаны, здесь думаю проблем не будет. Поэтому решили пойти с конца и попробовать сначала создание и заполнение документов в БЭСТ. И сразу возникли проблемы. Как рекомендовано во многих темах, попытался разобрать пример генерации накладной - ничего не понятно:
1. Я так понял, что ScladDocs() и ScladDoc() это функции. Но описания их найти не удалось. Судя по всему, они ориентированы на работу только в товарах. А для кассы есть что-нибудь подобное?
2. AddRow() и AddDoc() тоже, я так понял, функции. Описания также найти не удалось.
3. После того, как документы будут автоматически сформированы В БЭСТ, сформируются ли автоматически проводки по каждому документу на основе кода типовой операции?

Буду очень благодарен, если Вас не затруднит, помимо ответов, придать хотябы общее решению данной задачи, поскольку на данный момент с теми данными, что удалось почерпнуть из справки, у меня только один вариант решения - прямая запись в файл. Но, во-перых, боюсь, поскольку не знаю принципов формирования различных ID и на что повлияет их отсутствие, во-вторых, в этом случае проводки автоматически формироваться не будут (а это не допустимо).

Цитата
nordk пишет: Очень похоже на то, что эти группы имеют под собой объектом учета сортовой принцип - по номенклатуре. Посмотрите для начала файл привязки групп к счетам на предмет двойной записи

Большое спасибо за подсказку. Проблема оказалась именно там.
По этим группам были созданы записи с "пустым" счетом. Удалил их, и проблема ушла.
Напрашивается , почему восстановление данных не отловило такой явный косяк?
Может стоит добавить подобный контроль?

А по остальным вопросам:

Цитата
nordk пишет: Я читал все это и у меня другой : а откуда такие сложности при работе с партиями ? Почему через модель калькуляции это дело не настраиваете ? Почему партии не автоматически создаете ?

Без разницы каким образом создается партия, проблема оставалась.

Цитата
nordk пишет: Вообще-то цена заполняется когда Вы выбираете партию повторно. А при первом вводе они должны быть равны нулю.... Я честно ОЧЕНЬ пытаюсь понять как Вы работаете и пока как то все сложно очень...

Заполняется при первом вводе.

Цитата
nordk пишет: Это регулирования прайс-листа. Если он у Вас по партиям то в mlabel смотреть и не надо.

В том-то и дело что по партиям, а mlabel заполнялся, хоть и не должен.

На данный момент установлен БЭСТ5-3.4 SP 23 hf 21.
В модуле "Товары. Продукция" в настройке счетов учета ТМЦ один из счетов настроен следующим образом:
Способ хранения - Партионный
Метод учета - По учетным ценам
Объект учета - Ном.номер+Партия
Метод списания - По учетным ценам (для бух. и нал. учета)
Вкл. в прайс-лист - ДА

В схеме хранения на одном из складов к этому счету привязано несколько групп товаров (на других складах этих групп нет). Группы настроены абсолютно идентично (сравнивали как в справочнике групп, так и в файле - все одинаково). Не смотря на это, 2 группы работают не так как остальные. Проблема в следующем: создаем документ прихода, выбираем одну из этих групп, далее либо выбираем уже существующую номенклатуру, либо заводим новую, создаем партию и проставляем в ней цены. Вот здесь возникает первое отличие от правильно работающих групп - в карточке партии нет возможности проставить учетную цену (левое нижнее поле в карточке партии)- программа не пускает в это поле, но при этом дает заполнить три оставшихся поля с ценами, в результате для всех партий данной группы учетная цена равна нулю. (Если же выполнить ту же самую операцию для других, правильно работающих групп, то данное поле заполняется без проблем.)
Далее выбираем эту партию, ставим количество, но при этом поля "Цена поставщика" и "Сумма поставки" не заполняются, а остаются равными 0. Если если же эти поля "Цена поставщика" и "Сумма поставки" заполнить вручную, то документ формируется правильно, однако дальнейщая работа с данной номенклатурой происходит как будто эти поля не заполнены.
Это выражается, например, в том, что если сделать полный расчет прайс листа, либо сделать для данной номенклатуры расчет цен по документу прихода, то цена не считается, а остается равной 0 (в формуле пробовали использовать параметры SPP и SPPV). Для номенклатур других групп эти же формулы отрабатывают.

Проанализировав файлы каталога Sclad, нашли следующие различия:
У правильно работающих групп у номенклатур в файле spr_part.dbf заполнены оба поля CENA_P и CENA_F, а поле NASENKA равно нулю. После расчета прайс-листа, для этих групп цена прайс-листа появляется так же в файле spr_part.dbf поля OCENA1 и VCENA1. А в файле mlabel.dbf для этих номенклатур никаких цен нет.
У не правильно работающих групп у номенклатур в файле spr_part.dbf заполнено только поле CENA_P а CENA_F равно 0, в результате поле NASENKA имеет отрицательное значение. После расчета прайс-листа, для этих групп файле spr_part.dbf поля OCENA1 и VCENA1 равны нулю. А цена прайс-листа появляется в файле mlabel.dbf в полях OCENA1 и VCENA1. То есть она все-таки расчитывается, но в программе не видна и не используется.

В результате всего этого при работе с данными группами возникает чехарда с ценами.
Восстановление целостности данных делали - не помогло.

Подскажите, пожалуйста, в чем может быть проблема? Где искать и что поправить?

Спасибо.
Выгрузка прошла.

Цитата
Юлия Астахова пишет: Здравствуйте! Подобная ошибка возникала, если не было заполнено поле "Категория застрахованного лица". После ошибки формируются ли какие-либо файлы. И если да, то какие. Если есть возможность выложите пожалуйста папку Salary. Если не можете выложить все файлы, то нужны Salary\cardspri.dbf, cardssec.dbf, szv4.dbf, NP\stag.dbf

Поле "Категория застрахованного лица" заполнено.
Несколько файлов успевает сформироваться до возникновения ошибки.
Целиком каталог зарплаты отправить нет возможности, он слишком большого размера.
Указанные Вами файлы и то что успело сформироваться до возникновения ошибки отправил на Consult@bestnet.ru
и продублировал по указанной Вами ссылке в корневой каталог, файл Salary.zip

Установили 21 hotfix, заново провели подготовку данных (пробовали ставить и 400 и 200 человек в пачке).
Начинаем формировать файл и получаем уже другую ошибку:

Пpи oткpытии reestr вoзниклa oшибкa:
xml_ainsert c:\best\best5_34\client\bin\bdfutils.prg Error in line 663 Invalid subscript reference. 31

Удивительно то, что файла bdfutils.prg нет не только в папке client\bin, но и вообще в каталоге БЭСТ даже на сервере.
При этом файлы СЗВ4-2 замечательно формируются и на 19 и на 21 hotfix.

Что делать? Теперь уже надо ОЧЕНЬ срочно!

Цитата
Галина Яковлева пишет: Алексей, добрый день! Ошибка возникает из-за количества строк (записей) в XML-файле, превышающее 32000. Проблема будет решена в ближайшее время (возможно, завтра 09.07.2010 г), в крайнем случае в понедельник.

Спасибо. Ждем.
Хотя как-то странно. Строк в файле конечно много, но не 32000, а чуть больше 3000.

Цитата
Денис пишет: Похожая проблема перадана разработчикам (ID=15820)

Где это?

Цитата
Zoha пишет: Сегодня столкнулся с такой проблемой у одного из клиентов. Количество лицевых счетов около 1000. Помогла поэтапная выгрузка (фильтровал по категории кадрового состава, отдельно подготавливал по отмеченным сотрудникам и выгружал отдельными пачками), далее загружал в Документы ПУ 5, все прошло корректно.

Спасибо, как вариант возможно, но не хотелось бы.
Причина: кадров нет, на некоторых сотрудников заведено несколько карточек. При входе в редактирование подготовленных данных, программа сама находит дублирующиеся карточки и предлагает их объединить. Это сильно упрощает последующую корректировку данных (сотрудников больше 2500).

Цитата
Людмила Квасова пишет: Просьба прислать еще файл stag.dbf. (salary\np\stag.dbf)

Отправил, но он пустой (в нем нет записей).

Цитата
Людмила Квасова пишет: Пришлите пожалуйста подготовленный файл szv4.dbf и из папки Salary файл cardspri.dbf на адрес Consult@bestnet.ru

Отправил.
С нетерпением ждем результатов.

А по нашей ошибке ни у кого мыслей нет?

Могу выложить куда-нибудь файл szv4.dbf (базу, и даже каталог зарплаты выложить не могу, они огромные).

Установили hotfix 19 то 02.07.2010 (до этого стоял hotfix 9).
Подготовка данных для выгрузки в ПФ проходит без проблем. Редактирование подготовленных данных тоже работает (проверили выборочно нескольких сотрудников - данные правильные).
Но при выгрузке данных в файлы (Сведения о страховых взносах СЗВ-6) в процессе формирования возникает следующая ошибка:

Пpи oткpытии reestr вoзниклa oшибкa:
szv_6_2.openarea c:\best\best5_34\server\data\pro\datasource\salary_export.vct Error in line 974 Numeric overflow. Data was lost. 39

Несколько раз переделывали подготовку данных с разными настройками, переставили hotfix 19 на серверную, клиентские части, и на базу данных, еще несколько раз проводили подготовку данных. Ничего не помогает, ошибка остается.
В каталоге зарплаты нашли файл с подготовленными данными szv4.dbf и удалили из него все строки, которые вызывали хоть какое-то подозрение (нет страхового номера, ФИО или стажа). Остались только однозначно корректные записи. Ошибка все равно осталась.
Подскажите в чем может быть проблема? Сотрудников очень много, и забивать их вручную в программу пенсионного фонда не реально.