Расчет налога. Вопросы

Байтик

День добрый
Коллеги, у меня вопрос по формированию суммы налога.
Иногда возникает ситуация, при которой не определяется значение триггера налога MW01. При анализе выводится сообщение "Запись условий существует, но не настроена". В результате сумма НДС по позиции = 0.
Для повторно добавленной позиции этого же материала с одинаковым кол-ом и ценой значение триггера налога MW01 определяется. Соответственно, сумма налога корректно вычисляется.

Проверялись
1. Настройки последовательностей доступа - все нужные есть
2. Значение триггера налога определяется по группе цен материала - значение в позиции присутствует
3. Наличие записей условия - все есть
4. Код НДС определяется

Может кто-нибудь сталкивался с подобным и подскажет как решить проблему?
Рад буду за мысли, которые могут натолкнуть

Utenok

У меня была похожая ситуация, когда использовались несколько полей Группа Цен Материала и не подтягивалось значение из записи условий при изменении значения поля ГЦМ. При этом при обновлении расчета цен - все подтягивалось. Это не победить, потому что поля не предназначены для расчета налога.

Байтик

Utenok написала:

У меня была похожая ситуация, когда использовались несколько полей Группа Цен Материала и не подтягивалось значение из записи условий при изменении значения поля ГЦМ. При этом при обновлении расчета цен - все подтягивалось. Это не победить, потому что поля не предназначены для расчета налога.

У меня значение поля ГЦМ не меняется. Значение ГЦМ подтягивается из ОЗМ в позиую торгового документа.
Никаких изменений ГЦМ нет

. Не могут пользователи сознательно поменять ее. Они о ней даже не знают

Utenok

а обновить расчет пробовали? если помогает - значит проблема не в ваших настройках, а в том, что система при вводе не видит значения этих полей. в моем случае, мы в итоге отказались от использования ГЦМ, потому что каждый раз приходилось делать обновление.

Байтик

Нет. Не пробовал. На рабочей системе нет возможности, т.к. о проблеме сообщили уже по факту закрытия периода проводок.
Повторить не проблему не удалось.
Думаю, что при пересчете, расчет произошел, но это не решает проблемы. Лучше от этого не становится.
Вопрос в том, как можно попробовать не допустить повторного возникновения, т.с. устранить возможную причину...

troy

Борьба с последствиями: можно сделать поле VBAP-MWSBP (и/или соотв. ВУ) обязательным - и если сумма налога не была определена, то пользователь увидит сообщение, и будет думать что ему дальше делать.
Борьба с причинами: как заметил Utenok, у вас в определении налогов могут участвовать поля, которые для этого в стандарте не предназначены (при их изменении не происходит обновление налогов). В этом случае поможет userexit.

Angie

Сообщение № 108 класса VE написал(а):

This message tells you that the condition record exists, but has not been set in the document. If pricing was carried out again for the document item, then the condition would be set.

There are different reasons for this:

The condition was deleted manually in the item condition screen.
The condition record was created later. Please note that order processing and pricing have buffer mechanisms.
This means that a newly added condition record might only be found after order processing has been left completely and then started again.
If the condition type is used for subsequent settlement (rebate), there may be subsequent updating of business volume (the agreement is is created retrospectively). The document conditions do not contain the condition record, as the condition record was not created when pricing was carried out. Updating of business volume is carried out using special functions for subsequent settlement.
When an item was added, the condition record was accessed with key fields other than change time. This could lead to different results in the requirements check at the time of adding and the change time. This can occur when modifications are made.
In billing (or when copying orders): Certain condition types were not determined in the source document (this is usually controlled by the pricing requirements). When creating the document, the document flow (TVCPF,TVCPA) is processed using a pricing type that does not redetermine these condition types, although they are supposed to be called via the requirements.

PS: Идём в se80, переходим к классу сообщений VE и нужному сообщению из анализа расчёта цен. Читаем там подробный текст. Часто бывает полезно.

Байтик

Angie написал:

PS: Идём в se80, переходим к классу сообщений VE и нужному сообщению из анализа расчёта цен. Читаем там подробный текст. Часто бывает полезно.

Так-то лучше использовать либо язык EN, либо транзакцию se91. Для меня как-то проще. Читал я это.

Видимо придется

troy написал(а):

Борьба с последствиями: можно сделать поле VBAP-MWSBP (и/или соотв. ВУ) обязательным - и если сумма налога не была определена, то пользователь увидит сообщение, и будет думать что ему дальше делать.
Борьба с причинами: как заметил Utenok, у вас в определении налогов могут участвовать поля, которые для этого в стандарте не предназначены (при их изменении не происходит обновление налогов). В этом случае поможет userexit.

а точней проверять через userexit, т.к. есть ситуации, при которых налог должен быть 0

Байтик

troy написал(а):

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

Вот мне не понятно. группа цен материалов из ОЗМ является стандартным полем для определения налога или нет?

Utenok

нет, это не стандартные поля. убедиться в этом можно посмотрев в spro в разделе расчет цен каталог допустимых полей. нестандартные начинаются на Z.
также можно посмотреть через se12 структуру KOMP (позиция связи). опять же, собственные поля начинаются на Z.

Angie

Utenok написала:

нет, это не стандартные поля. убедиться в этом можно посмотрев в spro в разделе расчет цен каталог допустимых полей. нестандартные начинаются на Z.
также можно посмотреть через se12 структуру KOMP (позиция связи). опять же, собственные поля начинаются на Z.

Что-то я вас не совсем понял. Ведь поле KONDM благополучно везде есть.

troy

Утверждение тов.Utenok, конечно, не совсем верно. Но сути дела это не меняет.
Поле KONDM - стандартное (не начинается на Z :wink:

), но тем не менее, стандарно оно не предусмотрено для обновления цен.

to Байтик: проблема теперь, я думаю, ясна. Если в ОЗМ не указана группа цен, и ее вводят в позиции вручную, то код НДС не будет определен автоматически. В этом случае вам поможет USEREXIT_NEW_PRICING_VBAP с параметром NEW_PRICING = 'G'. Если же поле тянется из ОЗМ, и его никто не меняет - то смотрите причины, указанные Angie.

Utenok

Господа, я адски извиняюсь, я почему-то решила, что Байтик имеет ввиду поля Группа Цен Материала 1, 2 итд (MVGR1, 2 итд). прошу пардону, KONDM- конечно же стандартное )))

Байтик

troy написал(а):

проблема теперь, я думаю, ясна. Если в ОЗМ не указана группа цен, и ее вводят в позиции вручную, то код НДС не будет определен автоматически. В этом случае вам поможет USEREXIT_NEW_PRICING_VBAP с параметром NEW_PRICING = 'G'. Если же поле тянется из ОЗМ, и его никто не меняет - то смотрите причины, указанные Angie.

Так-то и не так.
Поле тянется из ОЗМ, но причины указанные Angie, вроде как, не подходят.
1. Запись не удалалась вручную

2. Вот только тут есть подозрения. Не могли быть доступ к записи условий блокирован каким либо процессом. Вообще, могла ли возникнуть ситуация при добавлении позиции был осуществлен поиск записи условия. Запись найдена. Отправлен запрос на получение данных и....тишина. Пользователь в это время сохраняет документ. В результате, ситуация описанная в первом посте.
???

3. Записи условия не менялись несколько лет и меняю их только Я
4. Проблема тянется из первого документа в потоке - сбытовой заказ.

Правила форума

Расчет налога. Вопросы

Кто сейчас на конференции