Округление при фактурировании

Dashutka

Добрый день!
сталкнулась с такой проблемой:
при выверке технического счета по НДС есть разница в 0,01 грн.
:cry:

причину нашла: разная сумма НДС в фактуре и налоговой накладной.
Более подробно:
Сумма поставки с НДС 3,45, при фактурировании сумму НДС считает как 0,57 (ставка 20%), а при генерации налоговой накладной 0,58.
Если исходить из стандартных правил округления, то верен вариант 0,58. Значит, программа генерации налоговых накладных считает правильно. Ошибку нужно искать при фактурировании.

Вопрос где настраивается, регулируется, корректируется округление при фактурировании сбытовой поставки? :?:

Jelena

B FAQ заглянуть не пробовали?

Цитата:

5. Между стоимостью заказа, поставки и фактуры есть расхождение на несколько копеек. Что делать?

ruporr

Jelena написала:

B FAQ заглянуть не пробовали?

Цитата:

5. Между стоимостью заказа, поставки и фактуры есть расхождение на несколько копеек. Что делать?

Jelena
А ВЫ для себя нашли что-нибудь???

Jelena

В США нет НДС, так что у нас нет таких проблем.

Но у нас были заморочки с округлением, когда цена за ящик пересчитывалась в цену за бутылку. Решено это было довольно брутально добавлением VOFM routine на pricing condition (к сожалению, не знаю как это все будет по-русски).

Путь в SPRO: Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define and Assign Pricing Procedures.

Потом click on Maintain Pricing Procedures, select procedure, click Control Data (в окошке слева). Номер VOFM routine вводится в загадочном поле AltCTy (Condition formula for alternative calculation type).

Сам код создается в транзакиции VOFM -> Formulas -> Condition Value.

ruporr

Вобщем была проблема:
есть правило исключения PB00(ручная цена) исключает DIFF(округление).
При вводе ручной цены PB00 всё равно вылазит DIFF !!!

Закончилось всё победой SAPa - пришлось разрешить ручное удаление DIFF . Т.е. если менеджер вводит ручную цену(оговоренную с покупателем) и вылазит DIFF , то он будет удалять его вручную.
Пользователи "очень рады".

У кого-то была такая-же проблема.

ruporr

Jelena написала:

Номер VOFM routine вводится в загадочном поле AltCTy (Condition formula for alternative calculation type).

Значит Вы указали какую-то подпрограмму расчета.
Не могли бы Вы скопировать текст этой подпрограммы?
"Source text" по Вашему.

Jelena

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

Не могли бы Вы скопировать текст этой подпрограммы?

Code:

    data: lmarm1  like marm,
          lmarm2  like marm,
          lxkwert like xkwert,
          unitprct TYPE p DECIMALS 1,
          unitprc  TYPE i,
          tmp TYPE i,
          csprc(10) TYPE n.

    if  xkomv-kschl ne 'ZPR0'
    and xkomv-kschl ne 'ZNPS'.
      exit.
    endif.
    check komp-vrkme ne 'CSE'.

    select single umrez umren
      into (lmarm1-umrez, lmarm1-umren)
      from marm
      where matnr = komp-matnr
        and meinh = 'CSE'.
    check sy-subrc = 0.

    select single umrez umren
      into (lmarm2-umrez, lmarm2-umren)
      from marm
      where matnr = komp-matnr
        and meinh = komp-vrkme.
    check sy-subrc = 0.

    lxkwert = xkwert.

    catch system-exceptions conversion_errors = 1
                            arithmetic_errors = 2.

      csprc    = xkomv-kbetr * 100.
      unitprct = ( csprc / lmarm1-umrez / lmarm1-umren )  "Price per bt
                * ( lmarm2-umrez / lmarm2-umren ) .        "Bt per unit
      unitprct =  ( unitprct + '4.4' ).            "round up unit price
      unitprc = unitprct / '100' . "remove dec after 100th place


      xkwert   = unitprc * komp-mgame / 1000.            "total price.

    endcatch.

    if sy-subrc ne 0.
*      Error during calculation - reset to original value
       xkwert = lxkwert.
    endif.

ruporr

Спасибо Jelena!

Наташа

Jelena написала:

В США нет НДС, так что у нас нет таких проблем.

Но у нас были заморочки с округлением, когда цена за ящик пересчитывалась в цену за бутылку. Решено это было довольно брутально добавлением VOFM routine на pricing condition (к сожалению, не знаю как это все будет по-русски).

Путь в SPRO: Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define and Assign Pricing Procedures.

Потом click on Maintain Pricing Procedures, select procedure, click Control Data (в окошке слева). Номер VOFM routine вводится в загадочном поле AltCTy (Condition formula for alternative calculation type).

Сам код создается в транзакиции VOFM -> Formulas -> Condition Value.

Добрый день!
Подскажите, пожалуйста, в каком месте должно находиться это поле! У нас есть следующие столбцы в этом экране (первые три не указываю): From
To
Manual
Required
Statistics
Print
SuTot
Reqt
CalType
BasType
AccKey
Accruals
Альтернативнй формулы расчета -нет!

Sergo

Наташа написала:

Добрый день!
Подскажите, пожалуйста, в каком месте должно находиться это поле! У нас есть следующие столбцы в этом экране (первые три не указываю): From
To
Manual
Required
Statistics
Print
SuTot
Reqt
CalType
BasType
AccKey
Accruals
Альтернативнй формулы расчета -нет!

Аглицкое название поля "Condition formula for alternative calculation type", но анлицкое имя у него не AltCTy, а CalType (V_T683S-KOFRM), в 4.7, 6.0, то есть это наше название "Формула условия к правилу расчёта".

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

Округление при фактурировании

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