Is it possible to post fixed tax amount in countries with tax jurisdiction (e.g. US)?

[Jelena_Perfiljeva]

We have an unusual request to post sales tax as fixed amount in the sales orders. Naturally, that also needs to flow into the billing document and post to accounting.

In this scenario, the sales are done in a third party system and the goal is to post the price and tax as fixed amount, exactly as that system calculated. (The issues of proper tax reporting and audit are outside of the scope of this question.)

We were able to make this work in countries where tax jurisdiction is not used. (Added new condition with Tax type and Amount instead of %.) However, if we use the same configuration for US or Canada, we end up with error FF805 "Tax statement is missing...". Via debugger and note search (e.g. this one), we concluded that tax jurisdiction conditions (JRn) must always be present for the countries with tax jurisdiction.

The attempt to simply add JR1 condition on top of the custom "flat tax amount" one did not help. The error happens in FM FI_TAX_SV_BSEG_BSET_GROSS because in T_BSET the field TXJDP is blank. (All other fields, including TXJCD are filled in correctly.) Brute-forcing TXJCD value into TXJDP in debugger resulted in a similar error down the road ("SYST: Tax jurisdiction code at lowest level not transferred").

There are several questions about posting the fixed tax amount but they're not about US/Canada and I've not found any evidence it is feasible. At this point I'm looking at least for information that would confirm is it's possible at all or just flat out not possible.

To reiterate, this is specifically about countries with tax jurisdiction (such as US/Canada), we have a solution for other countries.

[Ryan-Crosby]

Based on reviewing associated notes and the guided answers on tax determination I would think this is only possible with the tax jurisdiction countries if you fudge with the pricing procedures. I'd play in our sandbox but we don't generally need to apply tax so too much configuration would be missing our environment to play with it.

[AntonFarenyk]

I'd try what you did, manual condition with B calculation type, but in TAX procedure (OBYZ, OBQ3), instead of SD pricing procedure. TAx procedures are per country. Take the one you use in US and pick and add another step with a condition with B.  Then define a tax code with a GL on that step with <manual> condition type.

Another route  - If 3rd party tax soft is in use (vertex, sabrix, basware etc), it might be possible to define manual tax rule there, e.g. applicable to all jurisdictions.

[Jelena_Perfiljeva]

There is no option to comment on an answer, so it's rather silly I have to post this as an answer to my own question. But that's the UX we have in 2024.

@Ryan-Crosbythanks for a reply! We already have a custom pricing procedure, so that ship has sailed. There is a catch-22 here because in a normal US setup, we have a U... something condition, which is statistical and only acts as a "trigger" for JR.. (or XR.. the difference being XR is used with external tax software). And then whatever is in those JR... conditions it's what is going to accounting. JR.. conditions have special type 1..6 (= "tax jurisdiction").

I thought OK, I'll just add JR1 and put the value in it but that idea ends with missing tax code error. Tax code is maintained in condition records (VK11) and you can't do that with JR1 since it has no sequence assigned.

It's possible to create something like ZR1 I guess, but at this point you begin to wonder what else you might run into and if it's even a good idea.

[Ryan-Crosby]

We encountered this FF805 error during our first phase of our S4 go-live in early 2022. The SD consultant for our first SI setup a custom pricing procedure with MWST even though our main business is out of the US, and then it happened because of the missing JRx conditions with UTXJ. We were sort of in the reverse case where we needed regular calculations for the rare case where taxes applied, but the setup fouled up the execution in pricing. What I do recall is spinning in loops on the tax determination documentation and how it's all intended to work because a good chunk of the help/documentation is vague and "Hello World" like - ended up making more progress simply debugging the code and landed in some of the same spots you mentioned in your post.