DCLSUMPP.DBF "ДТ - платёжные документы"

[spkg]

Добрый день.
При выгрузке в DBF в таблице DCLSUMPP.DBF "ДТ - платёжные документы" в поле SUM_ALL - "Общая сумма по платежному документу" и в поле SUMPDOK - "Списываемая сумма по платежному документу" стоит всегда одинаковая сумма.
По логике (и описанию данных полей) в первом поле должна быть общаая сумма денег на платежке, а во втором та сумма, которую списывают. Это ошибка, или я не правильно все понимаю?
Данная информация нужна для учета платежных поручений.
Спасибо.

[Nick]

По идее вы правы, в поле SUM_ALL наверное должна быть полная (исходная) сумма платежки.

Вот только в ГТД этой информации нет, и взять ее программе неоткуда - это раз.

А во вторых, DBF-формат сейчас практически не используется, выгрузка идет в XML, а там поля аналогичного SUM_ALL нет. Поэтому и выгружать его особого смысла нет.

Если вы хотите вести учет платежек с помощью Альты - для этого не нужен DclSumPP, лучше использовать диалог платежек по кнопке "монетка" рядом с гр.Б.
В него вносятся сведения о платежках а хранятся они на SQL, в таблицах Transact (сами платежки) и TransND (списания по ГТД).

То есть у этого окна есть и старый DBF-режим, но в случае ГТД-ПРО естственно лучше SQL.

Если возникнут по этим таблицам вопросы - пишите.

[zonda]

кто пользуется редактором платежек? расскажите, работает данная функция хорошо?

[Сергей1970]

кто пользуется редактором платежек? расскажите, работает данная функция хорошо?

Нормально работает, за исключением двух вещей
1) Некоторые платёжки, когда заканиваются на них деньги, не обнуляются до конца ( остается что-нибудь типа 1.047563562 на 10 в минус 14-й степени ), обнуляю руками.
2) Нет возможности учесть выпуск под обеспечение, приходится "левую" ДТ делать с искусственным списанием и убирать её с глаз подальше.

А так работает, очень даже ничего

[zonda]

А у меня получается, что одна сумма списанна по декларациям, а остаток по платежному поручению совсем другой (намного больше).

[Сергей1970]

А у меня получается, что одна сумма списанна по декларациям, а остаток по платежному поручению совсем другой (намного больше).

Вы смотрите справа в окошке, куда делись деньги. Или начальный остаток неправильно задан

[zonda]

А у меня получается, что одна сумма списанна по декларациям, а остаток по платежному поручению совсем другой (намного больше).

Вы смотрите справа в окошке, куда делись деньги. Или начальный остаток неправильно задан

там перечень ТД, по которым произошло списание. Вряд ли начальный остаток неправильный, такая ситуация сразу по двум платежкам

[Сергей1970]

А у меня получается, что одна сумма списанна по декларациям, а остаток по платежному поручению совсем другой (намного больше).

Вы смотрите справа в окошке, куда делись деньги. Или начальный остаток неправильно задан

там перечень ТД, по которым произошло списание. Вряд ли начальный остаток неправильный, такая ситуация сразу по двум платежкам

Ну так проделайте операции по сложению и вычитанию и всё увидите, где что списано и где пропало, если действительно пропало

[zonda]

Ну так проделайте операции по сложению и вычитанию и всё увидите, где что списано и где пропало, если действительно пропало[/quote]

Я выгружал базу списания по платежкам c SQL сервера, там списана сумма, которая указана в разделе "Списание по ГТД", непонятно, почему не изменяется остаток на платежном поручении.

[alta_olg]

Вам надо связаться с техподдержкой, если есть проблема.

[Nick]

Нормально работает, за исключением двух вещей
1) Некоторые платёжки, когда заканиваются на них деньги, не обнуляются до конца ( остается что-нибудь типа
1.047563562 на 10 в минус 14-й степени ), обнуляю руками.

Спасибо за замечание, это произошло от того что в DBF поле было типа N15.2 и все вычисления делались точно, а в SQL используется float (он же real) и при любых расчетах накапливается небольшая погрешность. В очередной версии будет исправлено, все что меньше 0.01 округляется до нуля.

2) Нет возможности учесть выпуск под обеспечение, приходится "левую" ДТ делать с искусственным списанием и убирать её с глаз подальше.

Наверное КТС делается при выпуске под обеспечение? И платежки там прописаны? Если так - то в ближайших планах распространить систему списания платежек и на КТС тоже, в новостях программы обязательно напишем.

[Сергей1970]

Нормально работает, за исключением двух вещей
1) Некоторые платёжки, когда заканиваются на них деньги, не обнуляются до конца ( остается что-нибудь типа
1.047563562 на 10 в минус 14-й степени ), обнуляю руками.

Спасибо за замечание, это произошло от того что в DBF поле было типа N15.2 и все вычисления делались точно, а в SQL используется float (он же real) и при любых расчетах накапливается небольшая погрешность. В очередной версии будет исправлено, все что меньше 0.01 округляется до нуля.

2) Нет возможности учесть выпуск под обеспечение, приходится "левую" ДТ делать с искусственным списанием и убирать её с глаз подальше.

Наверное КТС делается при выпуске под обеспечение? И платежки там прописаны? Если так - то в ближайших планах распространить систему списания платежек и на КТС тоже, в новостях программы обязательно напишем.

КТС, конечно, делается. Но там нет платёжек как таковых, хотя 47-я графа есть .

[Nick]

В КТС есть поле для платежек, в гр.47 самое правое. Не все его заполняют, но есть.

А без этого - как программа узнает что это "выпуск под обеспечение" и откуда этот обеспечение списывать?

[Сергей1970]

В КТС есть поле для платежек, в гр.47 самое правое. Не все его заполняют, но есть.

А без этого - как программа узнает что это "выпуск под обеспечение" и откуда этот обеспечение списывать?

Оно то есть, но там же нет правила как заполнять. И даже если заполнить как-то, разве спишется с платежки что-либо? Почему бы не сделать желтую кнопку как в ДТ, а уж в редакторе платёжек выбрать с какой платёжки списывать. Сумма то в КТС есть

[Nick]

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

[Сергей1970]

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

ОК, спс