2023-02-07 1957918

1957918 - Poland Legal Change : Update Tax Reporting

Date (Sale of goods/services)
Version 1 Type SAP Note
Language Английский Master Language Английский
Priority Correction with high priority Category Legal change
Release Status Released for Customer Released On 23.12.2013
Component XX-CSC-PL-FI ( use FI-LOC-FI-PL )

Please find the original document at https://launchpad.support.sap.com/#/notes/ 1957918

Symptom

As per the Poland Legal change that comes into effect on January 1, 2014, the tax reporting date(VATDATE)
that appears on the accounting documents

• For sale of goods or services: VATDATE is derived from good/services supply.

Usually, the delivery of goods/services to customer happen prior to the invoicing of the same and the
VATDATE that appears in the financial accounting document that is generated as part of invoicing has
VATDATE set as invoice date or as per the customer specific rules.

The following cases are affected as per the change in the law, as can be foreseen now.

• The goods are delivered to a customer after they have been invoiced.
• The services are delivered to a customer after they have been invoiced.

Other Terms

BKPF-VATDATE, Tax Reporting Date, Poland, Goods issue, outgoing delivery document, VL01N, VF01.

Reason and Prerequisites

Legal Change w.e.f 01.01.2014

Pre-requisites

1. The SAP solution to move the VAT DATE as 31.12.9999 when an invoice is posted as per the
information provided in the SAP note 1947124.
2. If the delivery happens after the invoicing, the VATDATE in the accounting document is populated with
the date 31.12.9999 when the outgoing invoices are being captured in the SAP system.
3. There is only one outgoing delivery to an invoice that has already been sent to the customer. In case
there are multiple deliveries linked to an invoice, this requires a change in business for the solution to
be working in the customer landscape or a customer specific BAdI implementation needs to be created
and activated by the customer.
4. Tax reporting date is activated for the company code.
5. Supplied BADI implementation changes VAT data in FI document headers only in case it’s set to
31.12.9999. VAT date can be filled out automatically by SD-FI interface (sample implementation is
supplied in consulting note 1947124; this sample implementation sets VAT date to 31.12.9999 in case
of order-related billing of items with delivery status A or B).
6. The program is invoked at the time of good issue posting for delivery.

© 2023 SAP SE or an SAP affiliate company. All rights reserved 1 of 8

2023-02-07 1957918

7. The program changes VAT date only in documents of type (VBRK-VBTYP): M (Invoice), O (Credit
memo), P (Debit memo), 5 (Intercompany invoice), 6 (Intercompany credit memo).
8. The program does not change VAT date in cancelled documents. Cancelled documents are recognized
with help of filed VBRK-FKSTO (Billing document is cancelled).
9. Documents to be changed are read from document flow. The program reads all subsequent documents
(of type M, O, P, 5 and 6) related to delivery and related to reference document (LIPS-VGBEL).
10. The program does not change back VAT date in case of goods issue cancellation.

Solution

Corrections will be available in next support package.

If you need corrections immediately,Implement the Correction Instructions delivered along with this note for
your release.
Please refer to the Correction Instructions tab for the corrections relevant for your release.

The latest legal change needs the automatic update of the VATDATE as per the business case and also
based on the actual incoming/outgoing goods /service dates.

In case of VATDATE being captured at time of capturing of outgoing invoices for goods, the BKPF-VATDATE
should be provided with the date 31.12.9999 for the automatic update to be triggered. The SAP note 1947124
should be implemented prior to this solution for the streamlined to ensure VATDATE be populated with
31.12.9999.

In case the VATDATE does not correspond to 31.12.9999, the VATDATE is not updated with the actual
Goods Issue date as per the outgoing delivery document.

The date that is being considered for the VATDATE depends on the configuration maintained in SPRO:

Financial Accounting->Financial Accounting Global Settings->Tax on sales and Purchase->Calculation-

>Assign Company Code to Document Date for Tax Determination (Transaction Code:OBCK)

The functionality of the tax reporting date should be activated also.

Please refer the attachment for creation of the enhancement implementation for the BAdI.

Case 1: Tax Determination based on document date is already set for the company code.

In this case, the document date will be taken. The corresponding accounting document that was generated
when sales invoice information was captured will be updated with the outgoing delivery document date.

Case 2: The company code follows the default configuration of using posting date of documents as
tax determination date

In this case of the delivery, posting date will be considered for the update process. The corresponding
accounting document that was generated when a sales invoice information was captured will be updated with
the outgoing delivery document's posting date.

Assumptions

1. The date that forms the basis of the legal change is the delivery date of the document that is being
linked to the invoice(through sales order in SD module). In case the invoice has a delivery already
linked to it, then the legal change will not be applied.
2. Each sales invoice has and will have only 1 delivery document linked to it(through sales order in SD
module).
3. An invoice already has no delivery date/ Tax reporting date linked to it and has the Tax reporting date

© 2023 SAP SE or an SAP affiliate company. All rights reserved 2 of 8

2023-02-07 1957918

set as 31.12.9999 manually or by customer specific process.

4. Tax reporting date is active.
5. The company code where the goods/services are delivered from, is located in PL.
6. The reversal and reversed documents are not considered for the automatic update process.
7. The correction invoices are considered for the automatic update process
8. In case if a service delivery is handled outside SAP (there is no service delivery confirmation in the
system), then the Tax reporting date - VATDATE in the corresponding accounting document, needs to
be updated manually.

Exceptions

If a customer needs to have an enhanced of the standard logic delivered / a different date to be considered
for updating the Tax reporting date, then the customer should create their own customer specific
implementation of the BAdI; for the issue of goods/services.

In case of services, if the automatic VATDATE cannot be triggered, the customer should manually update the
VATDATE in the corresponding accounting document via FI transactions.

Business Cases and Legal Change Validity Matrix

VATDATE updated with this

Sl.No Business Case VATDATE
solution
as per delivery
SO Created -> delivery document created -> date or as per
1 Not Valid
Invoice issued to the customer customer specific
rules maintained
SO created-> customer invoice posted ->
2 delivery generated but delivery was generated old rules apply Not Valid
before 01.01.2014
SO created prior to 2014, customer invoice
posted / on or after the 01.01.2014, the as per invoice
company has document date set as the date for date or as per
3 Not Valid
the tax determination. The goods issue(delivery customer specific
document)was done before 01.01.2014,but rules maintained
posted after 01.01.2014
SO created prior to 2014, customer invoice
posted on or after the 01.01.2014, the company Set as 31.12.9999
Valid -> the update process will
has posting date set as the date for the tax when the
4 set the GR posting date as the
determination. The goods issue(delivery customer invoices
VATDATE
document)was done before 01.01.2014,but were captured
posted after 01.01.2014
SO created prior to 2014, customer invoice Set as a different
posted on or after the 01.01.2014, the company date than
has posting date set as the date for the tax 31.12.9999, when Not Valid -> no change in
5
determination. The goods issue(delivery invoice was VATDATE
document)was done before 01.01.2014,but captured and
posted after 01.01.2014 posted
SO created prior to 2014, customer invoice Set as 31.12.9999
Valid -> the update process will
posted on or after the 01.01.2014, the company when the
6 set the Goods Issue document
has document date set as the date for the tax customer invoices
date as the VATDATE
determination. The goods issue(delivery were captured

© 2023 SAP SE or an SAP affiliate company. All rights reserved 3 of 8

2023-02-07 1957918
document)was done on or after 01.01.2014 and
posted after 01.01.2014
SO created prior to 2014, customer invoice Set as a different
posted on or after the 01.01.2014, the company date than
has document date set as the date for the tax 31.12.9999, when Not Valid -> no change in
7
determination. The goods issue(delivery invoice was VATDATE
document)was done on or after 01.01.2014 and captured and
posted after 01.01.2014 posted
Valid only for new invoice-> No
The invoice was reversed and then posted
change in VATDATE on the
8 again. Good issue/ outgoing delivery happens
first original or the canceled
on or after 01.01.2014
document
SO created and invoice was created after Not Valid-> The VATDATE
01.01.2014 for the entire quantity of goods would have been set when the
Set as 31.12.9999
mentioned in SO. One Goods Issue document, first good issue (delivery)
when the
say Doc1, was created after 01.01.2014 with document was posted. No
9 customer invoice
partial quantity and another Goods Issue change on VATDATE is
was created and
document was done for the same SO for the triggered when the second
posted
remaining quantity on or after the first Goods good issue (delivery)
Issue document was posted documents posted
Set as 31.12.9999
Company code in Poland has Plants abroad when the Valid->VATDATE is set on
10 active and the plant where the goods are customer invoice company code level and not on
received is outside PL . was created and plant level
posted
Set as 31.12.9999
Not VALID -> as VATDATE
A company outside Poland , but has plants when the
settings are done on company
11 abroad active , has a plant in Poland where the customer invoice
code level and not on plant
goods are issued on or after 01.01.2014. was created and
level
posted

Customer Enhancements - When to do and how to do

Customer enhancements to this solution is to be done, if a customer wants to override the standard
functionality of the automatic update delivered via this note .A few examples are cited below for reference .

• Override the date conditions currently set for the date determination for VATDATE

A company code has document date set as tax determination in the transaction : OBCK, but for
some reasons the VATDATE that needs to be updated automatically ( under the context of the
current legal change) is the posting date . In such cases, the customer needs to create own
implementation of BAdi and copy& change the standard solution / include own logic. No change
should be done in the standard implementation delivered by SAP via this note.

• Multiple deliveries linked to same invoice

For the current solution for the automatic update of the VATDATE , w.r.t the legal change solution
delivered via this note, in case a company has multiple deliveries linked to an invoice posted to a
customer, then they need to adjust the business process to ensure that one invoice has only one
goods issue(delivery document)document linked to it. In case the company prefers to follow the 1:N
relationship between customer invoice posted / sent and subsequent goods issue, then the
customer should proceed to have the customer implementation of the BAdi and deactivate the

© 2023 SAP SE or an SAP affiliate company. All rights reserved 4 of 8

2023-02-07 1957918

standard implementation. In the customer implementation, customer can include the logic they
would need to have the legal compliance adhered.

How to proceed with customer enhancements

To create the customer implementation for implementing customer specific corrections/ enhancements that
are out of scope from the standard solution , following steps needs to be followed

Step 1: Go to transaction code : SE18 (BAdi builder : Initial Screen for definitions).

Step 2: Provide the BAdi name as LE_SHP_GOODSMOVEMENT

Step 3: Navigate to the option of Enhancement Implementation on the Menu bar and select the option of
"Create".

Step 3.1 : A new popup appears where in the new customer specific implementation name has to be
provided. Provide a name that lies in the customer namespace and press "Enter" button

Step 3.2 : In the subsequent screen that appears, provide an appropriate text for the Implementation .

Step 3.3 : Navigate to the tab- "Interface" and check if the implementation class name has been assigned by
the system and it complies with a naming convention which is in line with customer namespace .

Step 3.4: Double click on the method name :LE_SHP_GOODSMOVEMENT.

Step 3.5 : A new popup appears prompting to save the BAdi implementation steps completed till this SOint .
Press "Yes" and continue

Step 3.6 :Assign the package name which is not the SAP standard package but, one that is in the customer
namespace.

Step 3.7 :Press "Save" icon to save the changes in the customer package

Step3.8 : A new information popup appears. Press "Enter" and continue with the process.

Step 4. A new popup window appears listing all the enhancement implementations that are available, where
the current implementation can be linked to

Step 4.1 : Create a new enhancement implementation by clicking on the "Create" icon that appears at the
right hand side ( bottom of the popup).

Step 4.2: A new popup window appears for creating the new customer specific enhancement implementation.

Step 4.3: Provide an appropriate name for the new Enhancement Implementation and a short text for the
same .Press "Enter" and continue .

Step 4.4: Save it in the same package as was assigned in the step 3.6. Press "Save" icon to save the same
and continue.

Step 4.5: Assign the same to a request when prompted to do so .

Step 4.6: The implementation name would appear in the list of enhancement implementation available in the
landscape in the popup window that appears .

Step 4.7 : Select the implementation that was created using steps 4.1 to 4.4.

Step 5: The class builder is now available for editing the method for further enhancements .

© 2023 SAP SE or an SAP affiliate company. All rights reserved 5 of 8

2023-02-07 1957918

Step 5.1 : Add in customer specific logic here and activate the class after saving the same in a workbench
request.

Step 6 : Press "Back" button on the toolbar to navigate back .

Step 7 :The system takes you back to the Business Add-In Builder : Change window

Step 7.1: Press "Ctrl+F3" or press the "Activate" the button to activate the implementation created.

Step 7.2:Check the value in the "Runtime Behavior" .It should be "The implementation will be called".

Step 8 : Deactivate the standard implementation, if the standard implementation delivered via this note is
already available in system.

Step 8.1: Press "Back" button to navigate to the initial screen of the BAdi builder (SE18).

Step 8.2:Provide BAdi name as "LE_SHP_GOODSMOVEMENT".

Step 8.3:Navigate to the option of Enhancement Implementation on the Menu bar and select the option of
""Change".

Step 8.4: All implementation linked to this BAdi appear in a SOp-up window.

Step 8.5: From the list select "FIPL_SD_VATDATE_UPD", if this note was already implemented .

Step 8.6: Press "Enter" to continue.

Step 8.7:Press "Ctrl+F4" or press the Deactivate icon on the toolbar to de-activate the standard
implementation .

Step 8.8: Check the value in the "Runtime Behavior".It should be "The implementation will not be called".A
status message stating that the BAdi implementation has been deactivated will appear confirming that the
standard implementation will not be invoked during the posting of the goods issue(delivery
document)documents for automatic update of VATDATE in the underlying accounting document.

Software Components

Software Component Release

SAP_APPL 600 - 600

SAP_APPL 602 - 602

SAP_APPL 603 - 603

SAP_APPL 604 - 604

SAP_APPL 605 - 605

SAP_APPL 606 - 606

SAP_APPL 616 - 616

SAP_FIN 617 - 617

© 2023 SAP SE or an SAP affiliate company. All rights reserved 6 of 8

2023-02-07 1957918

Correction Instructions

Software Component From To Version Changed on ID

SAP_APPL 600 600 1 23.12.2013 08:57:21 0001679648

SAP_APPL 602 602 1 23.12.2013 11:03:00 0001679931

SAP_APPL 603 603 1 23.12.2013 16:07:25 0001680144

SAP_APPL 604 604 1 23.12.2013 16:08:11 0001680146

SAP_APPL 606 606 1 23.12.2013 16:13:42 0001680179

SAP_APPL 616 616 1 23.12.2013 16:15:50 0001680180

SAP_FIN 617 617 1 23.12.2013 17:25:05 0001680190

SAP_APPL 605 605 3 23.12.2013 17:23:32 0001680147

Other Components

Component Описание

XX-CSC-PL Poland

Support Package

Software Component Release Support Package

SAP_APPL 600 SAPKH60025

SAP_APPL 602 SAPKH60215

SAP_APPL 603 SAPKH60314

SAP_APPL 604 SAPKH60415

SAP_APPL 605 SAPKH60512

SAP_APPL 606 SAPKH60611

SAP_APPL 616 SAPKH61606

© 2023 SAP SE or an SAP affiliate company. All rights reserved 7 of 8

2023-02-07 1957918
SAP_FIN 617 SAPK-61704INSAPFIN

This document refers to

SAP Note/KBA Title

1947124 POLAND: transfer VAT due date from SD to FI (VATDATE) as of 01.01.2014

This document is referenced by

SAP
Title
Note/KBA

2170231 Performance Optimization of Update Tax Reporting Date

Poland Legal Change : Update Tax Reporting Date (Sale of goods/services)-Only for
2008420
SAP_FIN(700)

1931772 2014 VAT law changes, UE directive implementation

Attachments

File Name File Size Mime Type

PL_Manual_steps.pdf 358 application/pdf

Terms of use | Copyright | Trademark | Legal Disclosure | Privacy

© 2023 SAP SE or an SAP affiliate company. All rights reserved 8 of 8