Идентефикатор ТХО

[Алексей]

Есть одно ДО и три накладные на покупку.
Первая и третья накладная уже оплачены ранее.
Оплачиваем третью накладную. Один платеж на всю накладную. В распределении платежа платеж садится на нужную нам накладную.
При формировании проводок используется вот такой идентификатор &NP_[Расчет:Оплаченые]
До обновления на 5.4.33 всё работало как надо, получал одну проводку с суммой оплаты равной платежу.

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

Возможно алгоритм доработали, а возможно сломали! Может есть другой стандартный алгоритм? Не хотелось бы опять ТХО апи выдумывать.

З.Ы.: алгоритм нужен такой потому что по 60-му счету есть КАУ по С/Ф. т.е. часто оплачивают одним платежом 2-3 накладные - и проводки должны разбиться в разрезе С/Ф.

[Seybukan]

Есть сомнения, что дорабатывали именно NP.
Очевидно, что последнее время идет разработка только по ТХО АПИ. Так проще и не надо пересобирать половину финансов.
Возможно поломали именно атлантисом. Проверить можно только подключиться старым и грешить на новый.
Есть возможность проверить именно это утверждение?
Если это не ошибка возникшая из-за смены атлантиса, то надо разбираться с конкретными данными.

P.S. Dместо &NP_[Расчет:Оплаченые] можно использовать &Vip_[Obj:"PAYDIFFRATE"][Рез:СтоимПоз].

[Алексей]

Предложенный вами алгоритм работает, но вот только я никак не могу вытащить КАУ по С/Ф на отгрузку.
Раньше вытаскивал так:

Код: Выделить всё

coTXOGetField('KATSOPR','CSCHFACT', &KAU[Кау:80])
TxoSetKau(79,160,&1)

КАУ заполнялось, теперь же там пусто. если ставим в режим авто - берётся С/Ф по платежу, а нужна именно по отгрузке.

[Алексей]

Ещё вот что заметил, все алгоритмы выглядят вот так: &NP_[Расчет:Оплаченые]
а если после обновления заново по ф3 его выбирать, то новый выглядит вот так &NP_[Расчет:ОплаченНые]
добавилась буква Н - это значит - они его всё же доработали и сломали

Буду в ТП писать.

[edward_K]

внимательно прочитайте окно с параметрами в PAYDIFFRATE
там же написано - СФ по накладной режим 0.
Если н добавили - то скорей всего вы теперь переключились в другой режим. А ТП нельзя сразу обращаться?

[Алексей]

Хм. стоял у меня режим 0. Просто видимо дело было в том что были ещё 2 ключа такие как

Код: Выделить всё

coTXOGetField('KATSOPR','CSCHFACT', &KAU[Кау:80])
TxoSetKau(79,160,&1)

они то видимо и зануляли КАУ по С/Ф. убрал ключи, поставил циклическую обработку по С/Ф - заработало.

Спасибо!

З.Ы.: в ТП тож написал, но как показывает практика, зачастую быстрее решение находится здесь
Не охота переделывать ТХО, подожду что ответят.

[Алексей]

ТП прислала скрины со словами "у нас не подтверждается".

[LaaLaa]

Ещё вот что заметил, все алгоритмы выглядят вот так: &NP_[Расчет:Оплаченые]
а если после обновления заново по ф3 его выбирать, то новый выглядит вот так &NP_[Расчет:ОплаченНые]
добавилась буква Н - это значит - они его всё же доработали и сломали

Буду в ТП писать.

Проблема не в букве "Н" а в чем-то другом. При расчетах значение имеет только первая буква "О". Вот фрагмент кода разбора параметра.

Код: Выделить всё

      forParam := GetParam('РАСЧЕТ',SysKey);
      if ( length(forParam) > 0 ) then
        case forParam[1] of
          'О' : IdentParamList.BySpSoprHoz := true;      // [РАСЧЕТ:ОПЛАЧЕНЫЕ]
          'Н' : IdentParamList.NP_ByPlan := true;        // [РАСЧЕТ:НОМИНАЛЬН]
          'Р' : IdentParamList.NP_BySoprDopRasp := true; // [РАСЧЕТ:РАСПРЕДЕЛЕНИЕ]
          else _Err_(FormatString('Параметр %s имеет неизвестное значение: %s',['РАСЧЕТ',forParam]));
        end;

Опечатку слове &NP_[Расчет:ОплаченНые] исправили еще в 2005-м году. На расчет это не должно влиять.

Проблему нужно искать в чем-то другом. Вы отладочный протокол расчетов и распечатку ТХО посылали в ТП?

[Алексей]

ну это понятно, что не в орфографии дело
сейчас времени нет, в одной конкретной ТХО использовал указанный идентификатор из ТХОАпи. Появится ошибка ещё раз - буду детальней уже разбирать.