Алгоритм NP[Оплаченные]

[Иван]

Добрый день!
Подскажите, каким образом работает алгоритм &NP[Оплаченные] в платежном документе.
Вообщем есть ДО, на него навешана куча актов на услуги и куча платежек.
Вообщем одна из платежек на сумму 100 руб и она распределена на сумму актов 30, 20, 10, 10, 15, 15 руб, т.е. в сумме тоже на 100 руб.
При привязке ТХО алгоритм &NP[Оплаченные] почему-то выдает сумму типа 150 руб, хотя все 6 актов привязаны именно к этом ДО. В чем может быть косяк? В настройке ТХО стоит цикл по услугам и накладным.

[Seybukan]

Включите режим протоколирования при проведении ТХО.
Режим 4, только не помню какая настройка.

Вообщем там выдается протокол. В протоколе посмотрите из каких сумм сложилось 150 рублей.

[Иван]

так и делал, вообщем нашел этот лишний акт, на него была распределена другая платежка , а захватывалось в другую платежка
как будто два платежа распределены на один и тот же акт - перераспределял несколько раз на него и пока не удалил этот акт, ничего не получалось
как будто целостность данных никак не контролируется в базе - одна и та же информация хранится в 20ти местах

[Алексей]

была подобная ситуация, не отрабатывал этот алгоритм хоть убейся. вытаскивал ВСЮ сумму распределения платежа а мне нужно было по одной хоз.операции по одному сопроводительному.
при чем было это только в одной платежке.
заменил на &VIP_[Obj:"PAYDIFFRATE"][Рез:СтоимПоз] только в одной ТХО, в других оставил - работало все нормально.
в чем было дело - так и не понял. писал в ТП - ничего толком не ответили.

[Иван]

может кто-нибудь знает по каким таблицам и по каким связям между таблицами работает этот алгоритм?

[oiko]

soprhoz и spsophoz к шаману не ходи

[Иван]

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

[oiko]

То что видно красиво в интерфейсе не означает реально корректно сформированную связку этих 2 таблиц.
Давно написали отчет показывающий баланс по хронологии и баланс по этим двум таблицам.
Не было месяца чтобы они сходились.
Расхождения отрабатываем и тогда и проводки и регистрация с/ф отрабатывают корректно.
В чем-то поможет стандартная проверка хозопераций.

[Иван]

То что видно красиво в интерфейсе не означает реально корректно сформированную связку этих 2 таблиц.
Давно написали отчет показывающий баланс по хронологии и баланс по этим двум таблицам.
Не было месяца чтобы они сходились.
Расхождения отрабатываем и тогда и проводки и регистрация с/ф отрабатывают корректно.
В чем-то поможет стандартная проверка хозопераций.

связка из двух таблиц совпадает с тем , что в интерфейсе

[LaaLaa]

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

NP[Оплаченные] - может захватить услуги отнесенные на другого контрагента из связанных авктов можете их отфильтровать фильтрами для циклической обработки fUP fUS кажись. Еще с пересчетом валюты и суммовыми разницами в NP[Оплаченные] не все гибко.

Лучше действительно используйте другой алгоритм &VIP_[Obj:"PAYDIFFRATE"]

[Иван]

А этот алгоритм NP где-то внутри зашит и раскрыть точно по каким таблицам он работает не представляется возможным?

[edward_K]

Ну если вам LaaLaa говорит использовать другой, значит нужно другой. А так NP считается в g_txo.dll

[LaaLaa]

А этот алгоритм NP где-то внутри зашит и раскрыть точно по каким таблицам он работает не представляется возможным?

NP в своей работе использует очень моного таблиц с нетривиальной схемой их обработки и пересчетов: katsopr spsopr spsophoz soprhoz soprordb basedoc stepdoc. И несколько тысяч уникальных строк кода на паскале, только на вычисления конкретно по этому алгортиму.