Business place validation for related FI Transactions

[Jigang_Zhang张吉刚]

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 sanil0309

In the SAP system, assign the GST identification number for each business place in Customizing for Cross-Application Components, under General Application Functions  Business Place  Business Place Configuration. 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 General Application Functions  Business Place  Assign Business Places to Plants.

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.

User Exit to populate Business Place J_1I7_GET_BUSINESS_PLACE

The purpose of this user exit is to populate the field LS_J_1BBRANCH and perform the validation check for the business place.

To fetch the business place from the front-end screen for standard Tcode like FB60, the source will be the Program Name SAPLFDCB with Screen Number 0010.

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.