Business place validation for related FI Transactions
About Business Place in India GST
An organizational unit, a level below the company code, is used primarily for reporting taxes on sales and purchases. For each line of business, companies must register with the GSTN.
In the SAP system, the business place represents the political state. Typically, there must be one GSTIN per political state that the business operates in. The GSTIN obtained for every political state must be entered in the business place details.
(One correction here: A business place does not always correspond to a political state as highlighted at the start of the blog. A business place corresponds to a GSTIN Reg Number and an entity can have more than one GSTIN No in a state. The tax laws in India allow that) by Sanil Bhandari
In the SAP system, assign the GST identification number for each business place in Customizing for Cross-Application Components, under . Under the India group box, enter the GSTIN in the Tax Number 3 field.
Next, you assign the business place to a plant. You do this in Customizing for Cross-Application Components, under .
Major function module to determine Tax account based on the business place
The trigger point of Tax account determination logic is the Function module: J_1I_VAT_TAX_ACCOUNT_DETRMINE.
J_1I_VAT_TAX_ACCOUNT_DETRMINE contains the function module ‘J_1I7_GET_BUSINESS_PLACE‘ to fetch business place using customized logic, otherwise will fetch from table J_1IT030K -India Tax account determination ( T030K + BWMOD) by default.
Those two values will be the input parameters DYNAME&DYNUMB of DYNP_VALUES_READ. And the screen field for the business place is ‘INVFO–BUPLA’. Set value to DYNPREAD-FIELDNAME then append to Table for Reading Current Screen Values DYNPFIELDS.
data: wa_dynpfields type ty_dynpfields. wa_dynpfields-fieldname = 'INVFO-BUPLA'. append wa_dynpfields to it_dynpfields. call function 'DYNP_VALUES_READ' exporting dyname = dyn_program_name dynumb = dyn_screen_no translate_to_upper = 'X' tables dynpfields = it_dynpfields.
The same fetching logic will work for TCODE like ‘FV60’ ‘FB65’ ‘FV65’ ‘FB70’ ‘FB75’. For ‘FB70′ and ‘FB75’, the Screen number will be 0510.
For TCODE like FV50 which business place is item level instead of header level, and also share different screen program and screen number, so can’t using the same approach to fetch it.
But we can use the field symbol to get a copy from the system buffer like below:
constants: c_bseg(25) type c value '(SAPMF05A)BSEG'. field-symbols: <fs_bseg> type bseg. assign (c_ydrseg) to <fs_bseg>. * perform custom validation using <fs_bseg>-bupla
Above fetching logic will work for TCODE like ‘F-54’ ‘F–48′ ‘FBA7’ ‘F-29’ ‘FBA8’.
Besides, be aware of all those validations mentioned above are for Front-END only! If any other approach to create FI documents like using RFC through BAPI by an external system, need to do the same validation for Back-End which is definitely not enough with this FM only as it depends on specific TCODE, too complex to cover all the situations. Just think about the reverse processing with MR8M which could be no business place from the screen! A combination of user exits is required for sure.
The key is simple: Get the business place inside this J_1I7_GET_BUSINESS_PLACE no matter from where then carry on the value assignment& validation.