We have adapted the functionality of the Polish Localization Package to support NetSuite configurations where the Primary Book currency for a Polish business entity is not the Polish złoty. These changes enable the correct recording of transactions and accounting for them in tax returns. The modifications affect the following areas:

• transaction recording, especially where VAT is stated,
• support for sales document printouts,
• support for VAT registers,
• generation of tax returns and JPK files.

This functionality is available as part of an extended service package and is charged separately. For detailed information on costs and implementation, please contact our team.

The Bank Payments module of the Polish Localization Package, available under Oracle NetSuite, provides new output formats for generated payment files:

• Multicash PLI (Elixir 0) Credit Agricole – a dedicated format intended for Credit Agricole
• XML ISO w wersji 009 – a bank file in XML, version: ISO20022 (pain.001.001.09), supporting the processing of foreign and SEPA transfers. The new structure is to ultimately replace the current ISO20022 format (pain.001.001.03). Additionally, where structured address data is involved, the user can select one of the available options:
  • full adress data – within the scope of address data provided in the supplier’s directory that is available and automatically separable into fields;
  • required address data only – including exclusively the mandatory fields, such as country and city/town.

The .xml format is available as part of an extended service package and is charged separately. For detailed information on costs and implementation, please contact our team.

We have ensured support for VAT and CIT in line with the SLIM VAT regulationss, allowing taxpayers to apply a common exchange rate for VAT and CIT transactions. Enabling SLIM VAT support in Oracle NetSuite results in:

• setting a CIT rate that will be consistent with the VAT rate for sales transactions,
• setting a CIT rate for ameding documents that will be consistent with the amended document.

We have introduced a functionality enabling the consolidation of lines in sales transactions and the presentation of the grouped item on the PLP document printout, in tax returns, JPK files, and the .xml file for the KSeF system.

We have provided dedicated fields:

• PLP consolidate lines – a checkbox for enabling the mechanism for consolidating transaction lines;
• PLP consolidated line item – a field for specifying the good or service to be presented as a grouped line;
• PLP consolidated line quantity – the consolidated quantity;
• PLP consolidated line unit abbrev. – the unit of measure for the grouped line;
• PLP consolidated line description – an optional additional description of the final good or service.

Adding the appropriate information will enable the presentation of grouped data:

• on the PLP document printout:

• in the JPK_FA file:

• in the .xml KSeF file:

We have included an additional column in the VAT Sales Register displaying the place of supply of services. The value is imported from the Country field, indicated in the transaction Shipping address section.

Incorporation of an additional column will be shown in the report as the code of the country of dispatch.

We have expanded the SAF-T JPK KR generation mechanism to include the primary accounting book. This mechanism supports the multibooking functionality.

This improvement allows for generating a SAF-T for a specific book or multiple books simultaneously (Adjustment Book and Primary Book). This change unifies the functionalities of the Polish Localization Package in terms of accounting reports.

We have implemented optimisations in the Polish Localization Package by incorporating a query caching mechanism where documents are imported. This functionality improves data processing efficiency and reduces the time needed for creating documents thanks to query responses being stored in the system cache.

Examples of where the mechanism is employed:

• when importing multiple currency documents for the same date, the tool will only execute a single exchange rate query. The result will be cached and used for subsequent documents.
• if the same good with a GTU code is used multiple times, the good's code information will be retrieved only once.