Форум

База есть в Корневом каталоге FTP на 89.253.233.90.
Последняя EPP150610.7z

в приложении Товары. Продукция/Учет движения товаров/Реализация со склада/АРЕНДА
формируются счета на оплату "20 СЧЕТ НА ОПЛАТУ АРЕНДА"

А шаблон как выложить? Из базы не получите?
...
Шаблон выложил туда же на FTP

Цитата
Сергей Введенский пишет: Вывод счета в виде вещественного числа происходит когда в строке есть только цифры и её длина больше 11 символов

Спасибо, Сергей!
А почему это не всегда происходит. Рядом поля- корр/счет и р/сч, оба по 20 символов. Первый - нормально, второй- вещественное число?
И почему во втором случае - те же поля, а сохраняются верно, казалось бы все тот же Excel?

ОРИГИНАЛ куда-то делся

Цитата

[FILE ID=540967][FILE ID=540968][FILE ID=540966] День добрый! Обращаюсь повторно с одгним и тем же воросом. Суть в следующем. Общесистемная отчетность / Аналитические ведомости. Получаю любую, к примеру, Аналитическая справка по счету (портрет). Всё отлично. Но вот если зайти в режим редактирования (кликнув дважды правой кнопкой мышки), то исчезает название документа и период за который получена ведомость. Если выделить первое поле Наименование предприятия, то видно, что это поле перекрывает поле названия документа и следующие поля. Странно что исчезает (перекрывается) только одно поле, а остальные на месте. Если посмотреть на эти поля в Дизайнере отчетов, то там никакого перекрытия полей нет. Отчего - поля при отбражении на экране не соответвсуют заданным в ДО? - почему исчезают поля в режиме редактировани? Далее, пытаюсь запомнить полученный документ в формате Exel, Там есть два варианта этого типа : 1- Файл Excel- табличный экспорт (...) теряется название документа и период за который получена ведомость. 2-Файл Excel (...) здесь запоминает данный документ исправно. поэтому до последнего времени и пользовался вторым вариантом. К чему всё это обрисовал? Но недавно нарушился и этот вариант. У меня в приложении Товары. Продукция/Учет движения товаров формируются счета на оплату. Их я формировал с существующих в системы с настройкой на свои особенности. Так вот, там наблюдаетсмя та же картина с "перекрытием полей" - в Дизайнере отчетов нет никаких перекрытий, а в режиме редактирования полученного документа они перерываются? А при запоминаниия в файле Excel в 1-м варианте вместо расчетного счета печатается значение в виде вещественного числа и исчезают наименования Поставщика и Покупателя. А во втором варианте - номер расчетного счета печатается верно, и наименования контранентов печатаются, а исчезают их адреса. Когда-то Вы рекомендовали:

Цитата
Сергей Введенский пишет: Чтобы исправить это "по быстрому" у объектов с названием предприятия, названием документа и периода (и если ещё есть другие поля в заголовке - то у них тоже) свойство Stretched установите в значение False.

Но это помогло только для режима редактирования - не стали исчезать поля.
А для сохранения в формате EXCEL не помогает, одно поле появляется а другое исчезает.
Понимаю, что трудно не имея под рукой этой ситуации, но может понять в общем, когда печатетс вещественное число всектро реального, и когда исчезают поля?

Прилагаю картинки
1 оригинал сформированного
2 Excel 1 - р/сч в виде вещественного числа и отсутвуют адреса Поставщика и Покупателя..
3 Excel 2 - Отсутствуют наименования Поставщика и Покупателя
4 - вид в Дизайнере отчета

На картинке мелко? Увеличить нельзя?

[QUOTE]Ирина Глухова пишет:
формируется по данным режима Подготовка данных в приложении Заработная плата,
проверьте какое там максимальное число указано
[/QUOTE]


Вот что в Подготовке данных. (см.ниже, почему здесь его нет, хотя загружен)

Где здесь максимальное число и при чем тут максимальное число, когда в реалии всего 29 застрахованных лиц. И по алгоритму насчитывет действительно 29 человел (КОЛ_ЗАСТР = 29), а уже в отчете присваиваются какие-то значения? И почему надо было заменять рассчтитанное верное значение КОЛ_ЗАСТР = 29
Вы можете ответить на Вопрос ы, как они были заданы:

1.Во-первых, что это за условие ([kol_zap251]=0) and ([kol_zap251]>0), как возможно одновременно равно 0 и больше 0.
Или я что-то не понимаю?
2. Где можно посмотреть, как опредляется kol_zap251 и kol_zap252

3.Но главный , что в результате за цифру выдает, которая превышает Количество застрахованных лиц в два раза?
По алгоритму, что в данном Внешнем отчете этот показатель равен 29, а на титульном листе уже 58.


4. В карточке запроса , что появляется при Предварительном просмотре, есть показатель "Количество страниц раздела 6"
У меня там после расчета стоит 116.
116 тоже похоже задвоилось от 58х2

По поводу Горячей линии - там отбиваются от вопросов как только могут. Там же не разработчики, им по три недели надо разъяснять суть вопроса.
Если вам трудно отвечать на вопросы, зачем вы отвечаете формально. Надеюсь, участники форума помогут. Как я понимаю это форум, где могут обсуждать все участники форума .

Повторить ситуацию думаю уже не удасться. Она появилась вот почему.
Я на своем ПК не занимаюсь этими Приложениями, на то есть другие работники. И если что мне надо, то они мне готовили нужное.
А тут мне в отсутствие их понадобилась информация и вышел на неустранимую ошибку.
Когда стал разбираться с проблемой (стал перебирать значения параметров) сообщение об ошибке исчезло и не повторяется.
Это говорит о том, что исходное значение запроса не соответствовало заложеным в алгоритме требованиям. А после замены, сохранилось последнее, вот и исчезло сообщение об ошибке.
Но проблема с признаком Группа в запросе осталась, о чем я написал на основном форуме БЭСТ-5. Надеюсь программисты обратят .
А на "горячую линию" смысла нет писать. Там группа сопровожденния не считает это проблемой и ы до программистов не доходят. Либо они один ответ "на демобазе не наблюдается".
Спасибо за к у.

116 тоже похоже задвоилось от 58х2

На титульном листе этого отчета есть показатель "Количество застрахованных лиц", очень странную цифру выдает.

В отчете этот показатель определён как:
[trim(str([kol_z]))+REPLICATE('—', 6- LENGTH(trim(str([kol_z]))))]

-------------------------------------------------------------------

begin

kol_z:=[DialogForm.DataSet1." КОЛ_ЗАСТР "];

IF [kol_zap251]<>0 THEN kol_z:=[kol_zap251];

IF ([kol_zap251]=0) and ([kol_zap251]>0) THEN kol_z:=[kol_zap252];

end

Во-первых, что это за условие ([kol_zap251]=0) and ([kol_zap251]>0), как возможно одновременно равно 0 и больше 0.
Или я что-то не понимаю?
Где можно посмотреть, как опредляется kol_zap251 и kol_zap252

Но главный , что в результате за цифру выдает, которая превышает Количество застрахованных лиц в два раза?
По алгоритму, что в данном Внешнем отчете этот показатель равен 29, а на титульном листе уже 58.


Ну и попутно. В карточке запроса , что появляется при Предварительном просмотре, есть показатель "Количество страниц раздела 6"
У меня там после расчета стоит 116, которое я меняю на нужное, Но после каждого расчета всегда 116, откуда оно берется?

.

Некорретно отрабатывает запрос на формирования Ведомостей наличия.

К примеру, Ведомость наличия детальная на ДЕМО базе.

1. Выбираю группу 004. Формируется по группе 004. ОК!

2. Устанавливаю группу "Все" через справочник. Формируется по всем группам. ОК!

3. Повторяю формирование ведомости не меняя запрос ( в нем остался установленный признак "Все") . А формируется по группе 004!

Вывод: Если нужна ведомость по всем группам, т.е.значение группы "Все", то ее надо устанавливать при каждом запросе. Даже если она не меняется!
Иначе она отрабатывает только при первом выполнении ( в момент установки этого значения), а при повторении будет выбираться группа, которая была до установки признака "Все".

Это можно пронаблюдать и визуально.
Когда выбираешь значение группы через иерархический Справочник, то наименование выбранной группы подсвечивается выделенным цветом.
Когда устанавливаю значение группы "Все" через справочник, то в иерархический Справочник устанавливается на верхнюю строку
+ 00 ОС. Ведомость формируется нормально - по всем группам.
А когда запускаю формирование ведомости повторно и тут же смотрю на состояние иерархического Справочника, там установлено (подсвечена) на предыдущую группу.
Естественно и формируется ведомость по этой группе. Хотя в запросе стоит значение группы "Все"

Здравствуйте, Сергей!

-Не совсем понял, что Вы имеете ввиду, говоря что "запрос не обновляется каждый раз в соответствии с заданными признаками".

тоже самое, что и Вы пишите:

-Теоретически в полях карточки запроса должны проставляться те значения, которые были введены при предыдущем запуске отчета.

Если получится повторить ситуацию - напишите как это сделать.
- Я сегодня весь день "гонял" эти формы, набирая разные варианты запроса и в результате сообщение об ошибке перестало проявляться.
Буду следить.

Но причина похоже именно в признаке (поле) Группа.
Заметил следующее. Это поле никак не контролируется при вводе. Если некоторые поля можно ввести только из справочника, другие - контролируются и выдается сообщение о некорретном значении, то в этом поле можно набрать любой набор символов и запрос проходит. А в формируемой ведомости стоит группа из предыдущего запроса.
Вот у меня каким-то образом в запросе в поле Группа стояло значение "Все", т.е вполне реальное значение. Мне это значение и надо было. Я его не менял. А на самом деле в запросе участвовало другое значение, из предыдущего запроса. Вот оно и "кнфликтовало" с другими признаками запроса.

Сергей, а что значит сообщение "Ошибка восстановления параметров....", о чем оно говорит?
Я считаю, что данное сообщение до пользователя не должно доходить, оно из разряда системных и программист должен её не допускать, т.е контролировать все входые параметры, на соответствие, корректность и тд и тп. и только тогда обрабатывать запрос в соответвии с заданными значениями. Не так ли? А у нас получается типа того, что собираемся складывать числа, а на вход подаем буквы . Вот и получается, что сыпятся системные ошибки, в лучшем случае. А в худшем - происходит зависание.
Вы это лучше меня знаете, это и составляет понятие надежности программного обеспечения.

Цитата
Сергей Введенский пишет: Видимо в файл Server\Data\PRO\USERPARAMREP.dbf запомнились какие-то "кривые" значения из карточек запросов этих отчетов при их предыдущем формировании с конкретной рабочей станции. Теперь при очередном запуске отчета программа не может восстановить эти параметры в карточке запроса.

Сергей, спасибо огромное!
Я избавился от старого путем ввода в запросе конкретного значения признака Группа, а затем убрал его (установил опять "Все")
и старый запрос сбросился.
А вот почему запрос не обновляется каждый раз в соответвии с заданными признаками - непонятно?
Ведь должно быть именно так, тогда и не будет ситуации "запомнились какие-то "кривые"
значения". Так же?

снимаю.
Разобрался. Не обновляется запрос. Каким-то образом в запросе где-то сохранился показатель Группа.
Почему не обновляется запрос - этому у быть не здесь.

Имущество. Формирование отчетов. Ведомости наличия.
При формировании Ведомости наличия детальная и Ведомость наличия краткая выдаются сообщения, что в прилож. файле соответственно.
Далее, нажав на OK, формируется пустой отчет, только шапка, самой таблицы нет.
В то же время Ведомость наличия детальная (ландшафт) формируется без проблем.

Происходит это только на одной рабочей станции, на которой установлен БЭСТ. На других рабочих станциях все отчеты формируются исправно.

О чем говорит, что одна ведомость формируется без проблем, а другие - нет?
И почему это наблюдается только на одной из рабочих станций.

Мало откликов - никто не пользуется экспортом отчетности из БЭСТ5, так надо понимать?

А не пытались выяснить причину? К примеру, какие показатели не попадают в .xml? Правили (настраивали) ли Вы под себя алгоритмы внешних отчетов?
Как дальше выходите из этой ситуации? Экспортируете как есть, а потом правите как надо? Или перестали пользоваться экспортом, вручную заполняете отчетность для передачи в ИФНС?

Добрый день!
Обращаюсь прежде всего к пользователям, который экспортируют данные для передачи отчетности по электронным каналам связи в ИФНС, т.е. кто формирует файл с расширением .xml, в частности по БО (Ф1,2,3,4)

Первое. В сформированный файл .xml попадают не все показатели, присутствующие в сформированных внешних отчетах и сохраненных в архиве внешних отчетов. В исходном файле внешнего отчета есть, а в .xml их нет!
Наблюдается ли у кого-нибудь подобное?

Второе. В Форме 2 (да не только) есть вычитаемые показатели, которые в печатной форме отражаются в круглых скобках.
В файле .xml эти показатели сформированы с минусом. После загрузки в программные средства по передаче данных в электронном виде ( у нас это ТЕНЗОР, назовем его оператор)) все эти показатели для получения результата (прибыли) складываются, так как минус (признак вычитаемого показателя) на минус (значение в файле .xml ) дает плюс.
У вас наблюдается подобное? Загляните, пожалуйста, в файл .xml , если , к примеру, в поле строки 2120 Ф2 минус ?

По общению на Линии консультаций, меня не понимают, говорят что только у меня наблюдается подобное, обвиняя во всем опреатора.
Оператор же считает, что он прав. И каждый ссылается " Наша программа сертифицирована ФНС . У нас все верно".
А что, я единственный пользователь БЭСТ5 у опреатора ТЕНЗОР?

Общаюсь с коллегами, которые работают с 1С, у них нет эти минусов в .xml.

Убедительно прошу откликнуться, и сказать ситуацию по обоим случаям у вас.

P.S.
Вот нахожу информацию об обновлении версии 1С:

1С:Предприятие 8 Типовая конфигурация
Управление производственным предприятием, редакция 1.2

Версия 1.2.7

Новое в версии
Регламентная отчетность

• Изменения в электронном представлении форм регламентированной отчетности
  • Изменены правила именования файлов выгрузки данных налоговой и бухгалтерской отчетности в электронном виде в соответствии с приказом ФНС России от 13.04.2007 г. N ММ-3-13/230@. Новые правила именования файлов применяются при выгрузке данных отчетности с 01.07.2007.
  • Изменен порядок выгрузки вычитаемых показателей при представлении в электронном виде форм бухгалтерской отчетности: начиная с 01.07.2007, вычитаемые показатели выгружаются со знаком «плюс».
    
  
  

Ну где-то же они нашли что "вычитаемые показатели выгружаются со знаком «плюс»."

Вот вновь конкретная ситуация за 1 квартал 2014 года.
В БЭСТ получил индивидуальные сведения СЗВ и загрузил их в СБИС++ для передачи в ПФР.
РСВ-1 в СБИС++ не загружал, а заполнил вручную, т.к. СБИС++ пересчитывает все начисления от общей суммы, а не по каждому работнику.

В РСВ-1 получил:
Раздел 2,1
строка 204 База для начисления - 1956047,96
строка 205 Начислено СВ - 430330,55 (1956047,96*22%)

Раздел 1
строка 114 За последние 3 мес - 430330,55 (тоже что и в стр.205)

Раздел 2.5.1.
строка Итого графа 2 - 1956047,96
графа 3 - 430330,57 ( а не 430330,55!)

Напоминаю, что в РСВ-1 Раздел 2.1 считается от суммарного начисления по предприятияю 1956047,96*22%=430330,55
А в Разделе 2,5.1 взято из СЗВ, т.е. сложив начисления по каждому сотруднику отдельно и получив сумму 430330,57

ПФР не принимет отчет, выдавая протокол с ошибкой. На Вопрос отвечают- "Исправляйте как хотите, у вас ошибка."
Самое простое - исправить СБИС++ , подправить сумму в Разделе 2.5.1.
в строке Итого графа 3 - 430330,57 на 430330,55 (при этом и графа 2 соответсвовала бы графе 3 как это в Разделе 2.1 выглядит)
НО! СБИС++ не дает править Раздел 2.5.1.!
Что остаётся? - править в Разделе 2 начисления взносов. Но чтобы начисления взносов в Разделе 2.1 исправить на 430330,57,
нужно увеличить базу на N-ю сумму, т.е начисления по зарплате...что приведет к различию с бухгалтерским учетом.
И разъясняй потом при каждом случае почему разбегаются копейки...
Да дело даже и не в этом, а в том что приходится. каждый отчетный период, гонять эти копейки, а это время и ... наши нервы

Неужели все бухгалтеры так и "страдают" от этого?

Конечно, мне импонирует ответ

[QUOTE]Николай Иванов пишет:
Это прямое нарушение закона, в котором изложен алгоритм расчета взносов...рекомендовали клиентам затребовать в отделении ПФ письменное возражение на отчет
[/QUOTE]
Но это будут пустое сотрясание воздуха.
Кстати, а кто-нибудь из клиентов воспользовался Вашими рекомендациями?
И чем это закончилось?

[QUOTE]
Сергей Джулай пишет:
категорически не согласен. Если вам нужны какие-либо промежуточные округления,
то вы должны сами это делать.
[/QUOTE]

Промежуточные округления нужны не нам. Нам нужна правильно заполненная Справка.
- И как Вы предлагете нам это самим править, когда мы запускаем расчет и получаем готовую Справку с неправильными результатами.
Или предлагаете "перерисовывать" полученную справку?
Мы и так все перерасчитываем. Что бы получить к примеру РСВ-1( а там много атблиц), надо сначала вручную всё просчитать, т.е. собственно составить Расчет вручную,
Затем получить его В БЭСТ и каждую цифру сравнить, верно ли посчитано.
И это ПО, которое призвано упростить и облегчить работу бухгалтера.
Общаюсь с коллегами, большинство из них не пользуется отчетностью, а сразу заполняют её в средствах ПО электронной и отчетности.

P.S. Вот сам и делаю: лезу в Дизайнер отчета, вставляю дополнительные функцию округления. Для чего и задал [IMG] по функци округления.
И Расчет РСВ-1 сам себе строю в Дизайнере отчетов. Или скажете так и должно быть?




[QUOTE]Cергей Джулай пишет:
Все промежуточные вычисления должны делаться с
максимальной или, хотя бы не ниже чем точность в базе. [/QUOTE]

Я не знаю что и как там в базе должно быть, но когда из базы выбираются данные для конкретного назначения, они и должны оборабатываться именно для этого назначения.
Среднедневной заработок не промежуточное вычисление, это вполне обособленный показатель и представаляться с тремя (или сколькими там) знаками после запятой не может!

[QUOTE]Сергей Введенский пишет:
В каких ещё формах есть проблемы с округлением?
[/QUOTE] Спасибо. На сей момент неприпоминаются.


[QUOTE]Ирина Глухова пишет:
[QUOTE]Сергей
Введенский пишет:
Можете выложить базу, на которой эта ошибка
воспроизводится
[/QUOTE]
[/QUOTE]

Выложил .ftp://ftp.bestnet.ru/ElectroPromProekt/
Но похоже зесь уже не нужно?

Цитата
Сергей Введенский пишет: Напишите в каком поле отчета стоит неправильная цифра и что там должно быть при правильном округлении ?

Зарплата/Формирование отчетов/Списки и справки/Средний заработк/Записка расчет о среднем заработке для отпуск (Т-60)

Оборотная сторона формы № Т-60, верхня таблица Расчет оплаты отпуска:
см . приложенный файл

В левой части Сумма заработка за расчетный период составляет 88940,21


В правой части таблицы количество календарных дней, приходящиеся на расчетный период -> 211.14
Считается это так:
Шесть полностью отаботанных месяца
29,4*6 = 176,4
Два - неполностью
29,4/31*3 = 16,1225
29,4/30*19 = 18,62
-------------------
Итого 211,1425

В Справке печатется 211,14

И дальше печататся Среднедневной заработок 421,23,
который получается путём 88940,21/211,14
Но 88940,21/211,14 даёт результат 421,238 = 421,24

А в Справке 421,23 !

Что получается, только

88940,21/211,1425=421,233100...
или если округлить до 3-х знаков
88940,21/211,143= 421,23210...
а далее где-то округляется до 2-х знаков м получаете неверный результат 421,23

когда должно быть
88940,21/211,14=421,23808... =421,24 !!!

[QUOTE]Сергей Введенский пишет:
Можете выложить базу, на которой эта ошибка воспроизводится ?
[/QUOTE]Что, в каком виде, куда и главное как выложить? Архив? Более 25КБ...

Сергей, Спасибо!
Я уже обращался и получил вышеприведенный ответ:

Цитата
[Прокопенко, Виолетта -- 28/03/14 16:04:50] 1. Ошибку округления в Т-60 на ХФ10 получить не удалось

Хотя привожу при этом конкретный пример.

А там похоже ситауция такая: в алгоритме нет округлений нигде, а в Дизайнере отчетов указан формат 2 знака после запятой.
Тогда будет такое искажение результатов.
А возможно и друга причина