Functional changes introduced in Comarch ERP XL, version 2023.0
Framework schedule for Comarch ERP XL version in 2022.
Version number | Version type | Release date | Notes |
2023.1 | Version | February 2023 | |
2023.2 | Version | June 2023 | |
2024.0 | Version | December 2023 |
Planned software release dates are continuously updated on the Comarch Community (Społeczność Comarch): https://spolecznosc.comarch.pl/news/planowane-wersje-comarch-erp-xl-na-rok-2022-68716
Summary of applications that Comarch ERP XL 2023.0 cooperates with
Application | Version | Notes |
Comarch IBARD | 6.5.1 | |
wszystko.pl | Current version of www.wszystko.pl | |
Comarch e-Sklep | 2023.0 | |
Comarch B2B | Information in the documentation of the new version | |
Comarch Mobile
(Management (Zarządzanie), Sales (Sprzedaż), Monitoring (Monitorowanie), Service (Serwis)) |
2022.2.2 | |
Comarch WMS
(Management (Zarządzanie), Warehouse Manager (Magazynier)) |
2023.0.0 | |
Comarch Warehouse Manager (Comarch Magazynier) | 2022.0.0 | |
Comarch ERP XL HR | 2023.1.1 | |
Comarch HRM | 2023.0.1 | |
Comarch DMS
(Offline – stationary (stacjonarny), web (WWW)) |
2022.0.3 | |
Comarch ERP XL Business Intelligence
(Report book, Management panel, Configurator) |
2023.0 | |
Comarch ERP XL Business Intelligence
(BI Point) |
12.6 | |
XL2XML data migration | 10.0 | |
Comarch MES | 2023.0 | |
Comarch e-Reports (e-Sprawozdania) | 2023.0.0 | |
Comarch POS | 2023.0 | |
Comarch Shipping | Current version of shipping.comarch.com | |
Comarch Apfino | Current version of apfino.pl | |
Comarch sPrint | 0.5 | Beta version |
As of version 2022.1, due to changes in the core libraries of Comarch ERP XL, we are removing the possibility to convert databases older than version 2018.0. If you need to convert a database older than version 2018.0, the conversion must be performed in two steps:
1. First, convert the database to one of the versions in the range 2018.0–2022.0
2. Then convert to version 2022.1
Logistics
National e-Invoice System (Krajowy System e-Faktur, KSeF)
In terms of integration with the National e-Invoice System, version 2022.1 of the System provides functional elements of a demonstrative nature, aimed at familiarising Users with the planned handling of this integration. Version 2023.0 provides full integration with KSeF for exporting invoices and invoice corrections to both the Demo and production environments.
On December 1, 2022, a draft law amending the Value Added Tax Act and certain other acts, introducing mandatory invoicing in the National e-Invoice System and a proposal for the next version of the FA(2) e-invoice schema, was published on the website of the Government Legislation Centre.
The integration with KSeF, introduced in version 2023.0 of the System and described in this document, is based on existing regulations and the FA(1) schema
Invoice submission on the Demo environment serves to prepare the Company for the planned KSeF system becoming mandatory from 2024. Submitting an invoice to the production environment, on the other hand, is tantamount to introducing such an invoice into the economic circulation and should be done in a prudent manner.
The functionality for exporting invoices to KSeF is available under one of the following licensing methods:
-
-
- Comarch KSeF licence
- OCR package
-
During the promotional period until June 30, 2023, the function of exporting documents to the National e-Invoice System is free of charge.
User authentication in KSeF
Communication with the KSeF System requires appropriate authentication of the User on the KSeF platform. In Comarch ERP XL, it is possible to perform such authentication with a token and with a certificate. The relevant parameter on the User’s card determines which of the aforementioned methods is used.
Tokens are assigned on individual company stamps. Users have the option of entering/pasting a token generated directly in KSeF themselves, as well as the option of generating one using the Generate operation, available on a non-archival stamp on which a VAT ID (NIP) is given and on which no such token has yet been generated/assigned.
The token is generated based on the VAT ID (NIP) of the stamp and the certificate indicated by the User. The token generated in this way is given all the roles: accessing invoices, issuing invoices, viewing permissions, managing permissions.
Note: When generating a token, whether for the Demo environment or the Production environment, the actual certificate must be authenticated, but must be generated separately for each of the above environments. |
The User has the option of removing the token from the stamp by deleting the contents of the Token KSeF control. Removing this token from the stamp is not equivalent to deactivating it in KSeF. Such deactivation should be done directly in KSeF, e.g. at https://ksef-demo.mf.gov.pl/ and https://ksef.mf.gov.pl/ provided by the Ministry of Finance.
The token is copied onto the stamp created by archiving the previous stamp and when copying the stamp using the <Ctrl>+<Insert> method. However, simply changing the token does not archive the stamp.
The VAT ID (NIP) is not editable on a stamp with an assigned token, so in order to change the VAT ID (NIP) on it, the token must first be removed from the stamp.
If a token has been assigned to the company stamp assigned to the centre in the context of which the User is logged in and the Authentication with a token parameter is enabled in this Operator’s card, then such an Operator is authenticated in KSeF automatically. If a centre has not been assigned a stamp, the token assigned on the main centre’s stamp is used for authentication.
If the aforementioned parameter of the Operator card is disabled or no token has been defined on the stamp, then the User is required to indicate the certificate before the operation of submitting an invoice or downloading UPO.
The certificate indicated by the User is remembered by the System until the module is closed or the Operator’s working context is changed.
Note: An exception and at the same time a limitation in submission using a token concerns the serial submission of invoices made in batch mode, which is addressed in more detail in the System configuration section. KSeF does not then provide for authentication with a token. An indication of the certificate is required for such submission. |
KSeF sessions
Communication with the KSeF System takes place within the specific KSeF session of the respective User. In the case of an interactive submission, i.e. one made for a single document or a serial submission made with the Interactive session option of the Export multiple documents section referred to in the System configuration section, the session is established when the first document is submitted after logging in to Comarch ERP XL application. The submission of further invoices takes place within this session until it is closed. The session is closed during/as a result of:
Closing modules of Comarch ERP XL system
Change of Operator
Change of the Operator’s context
Closing of the session at the Operator’s request
Downloading UPO for the session in question
Information on the current interactive session of the current Operator is available in the System/KSeF session menu. Here, the User may terminate the session themselves or download UPO for documents submitted during the session.
In the case of a batch submission, i.e. a serial submission performed with the Batch file option of the Export multiple documents section, referred to in the System configuration section, each submission is performed in a separate session.
The number of the KSeF session within which the document was submitted is presented on the [KSeF] tab of the document form.
KSeF parameters in the System configuration
A new tab [KSeF] is now available in the Configuration window, with parameters for integration with the National e-Invoice System.
The aforementioned option determines whether the Company only tests the functionality of invoice submission to KSeF by working on the Demo version, i.e. by submitting invoices to the demo server of the Ministry of Finance, or whether it uses this functionality production-wise, i.e. by registering a fully structured e-invoice and submitting it to the production server of the Ministry of Finance.
Changing from the Demo environment to the Production environment should be a conscious decision on the part of the User, as submitting an invoice to the production environment means entering the invoice into the business cycle. When changing the environment to production, the System removes all defined tokens from the stamps as well as all information relating to existing KSeF operations on documents. Once an invoice has been sent to the KSeF production environment, it is no longer possible to change the environment back to Demo. Changes to the KSeF environment must be made when no other User is working in the System. The operator who changes the KSeF environment to production must confirm to be aware of the above operation.
Option determining how to export multiple documents simultaneously
When submitting a single document to KSeF, such a submission is made in an interactive session. During serial submission of multiple selected documents, however, the setting of the option in the Export multiple documents section determines how this submission is performed. Selecting the Interactive session option means that each of the selected invoices will be submitted in a separate file, while selecting the Batch file option means that they will all be submitted in one package.
Note: In the case of batch submission, it must be taken into account that if one/any of the invoices is deemed incorrect by KSeF, the entire document package will be rejected. |
Parameters for saving the file of the invoice submitted and the downloaded UPO as an attachment to the invoice
Version 2023.0 supports the functionality of attaching the .xml file of the submitted invoice and the .xml file of the downloaded UPO as invoice attachments. These attachments are created if the relevant parameter of the Save as attachment section is activated. Attachments created in this way are labelled with a new attachment type – KSeF file.
If the User decides to create the aforementioned attachment(s), then they have the option of choosing whether to save it in the database or as a link to a file saved on a drive. In the latter case, the User can indicate the directory in which these files are to be saved. This directory can also be indicated in Computer parameters/[Data exchange].
The principle of saving files is as follows: the file created is saved in the directory indicated for the User in Computer parameters, and if it is not indicated there, then in the general directory indicated in the system Configuration. If this path is not indicated either, then these files are placed in a directory named KSeFXML of the Comarch ERP XL installation directory. In the directories indicated above, subdirectories are created for each date with which files are created and they are placed in these subdirectories.
Parameters of the Submit during export section
In the aforementioned section, the User decides whether, for each invoice element, the quantity/price is to be sent for the main unit or the auxiliary unit used on the element, and also has the option to indicate whether the System is to submit a description from the invoice element in the file.
KSeF parameters on the document definition
Relevant parameters are added to the definition of FS, FSE, FSL and FEL documents for the handling of this type of document in the respective centre with regard to submission to KSeF.
The relevant option determines whether, by default, a document of this type is to be marked as subject to submission to KSeF. The User can choose from four options:
The Do not submit option means that these types of documents in a centre are not subject to submission to KSeF
The Submit option means that all documents of this type registered at the centre are to be marked as subject to submission to KSeF by default
The Outside the system option means that the documents are subject to submission to KSeF, but it will be performed outside the Comarch ERP XL System
Depending on counterparty option
The last option, in combination with the parameters on the counterparty’s card, determines whether the invoices recorded for the counterparty are subject to submission to KSeF, and if so, whether this will be done from within or outside the Comarch ERP XL System. By default, the Submit documents to KSeF of counterparty cards parameter is enabled, while the Outside the system parameter is disabled. The User can change their setting either directly on the counterparty card(s) or using the counterparty template.
The Automatically when approving parameter of the document definition, as the name suggests, determines whether a document should be automatically submitted to KSeF when it is approved either from a form or from a list. An optional semantic validation check of the document with the KSeF schema before approval is also supported. This is performed as long as the Verify in KSeF before approval parameter is enabled on the document definition. As the System first pre-verifies the correctness of the document before submitting it to KSeF, the KSeF verification parameter is automatically switched on when the submission parameter is selected during approval.
KSeF permissions on the operator card
Not every Operator can submit documents to KSeF/download UPO from KSeF. This possibility is determined by the Submitting invoices/Downloading UPO permission on their card. The Editing KSeF number parameter, on the other hand, determines whether the Operator can enter the KSeF number of the document and other information on the document’s submission to KSeF. Such editing is only possible on those documents that are marked as having been submitted to KSeF outside the system (e.g. they were sent by another system/application), as discussed later in this document. The Authentication with a token parameter determines whether the Operator is to be authenticated with a token, as described above.
KSeF parameters on sales invoice and correction forms
The [KSeF] tab is now available on the sales invoice and sales invoice correction forms, where the following information on document submission to KSeF is presented.
-
-
- Submit to KSeF parameter to determine whether the document is subject to submission to KSeF
- Outside the system parameter to indicate that the document has been/will be submitted to KSeF, but this will be done outside Comarch ERP XL
-
The aforementioned parameters are set by default based on the option selected in the Submitting a document to KSeF section of the document definition. If the option Do not submit is selected on the definition, then the aforementioned parameters are disabled by default, if the option Submit is selected, then the parameter Submit to KSeF is enabled and Outside the system is disabled, if the option Outside the system is selected on the definition, then both parameters on the document are enabled. If, on the other hand, the Depending on counterparty option is selected on the definition, then the parameters are determined by the KSeF parameter setting on the counterparty card for which the invoice is being recorded.
The aforementioned principle of setting parameters on the basis of the document definition also applies to the creation of a new document by copying <CTRL>+<Insert>, while on corrections the aforementioned parameters are set on the basis of the document being corrected.
Editing of the Submit to KSeF parameter is possible under the following conditions:
-
-
- The Operator is authorised to edit the document of this centre
- Document status is other than cancelled
- The Outside the system parameter is deactivated
- The document has not yet been submitted to KSeF
-
The User can also change the setting of the aforementioned parameter in a serial manner using the relevant context menu options of the FS/FSE list.
Editing of the Outside the system parameter is possible on a document that has not yet been submitted to KSeF, whereby:
-
-
- the parameter can be enabled as long as the Submit to KSeF parameter is enabled
- on an approved document it may only be edited by an Operator with the Editing KSeF number on documents permission
-
Selecting the Submit to KSeF/Outside the system parameter on the document means that the document has been/will be sent to KSeF outside the Comarch ERP XL System. On a document marked in this way, the Operator with the Editing KSeF number on documents permission can enter the following KSeF data themselves: the document KSeF number, the KSeF status, the session number, the document reference number and the dates of submitting/accepting/receiving the UPO.
-
-
- Document KSeF number
-
The aforementioned number is an invoice identification number, assigned by KSeF and recorded on the document after downloading the UPO.
-
-
- Document KSeF status
-
The KSeF status is changed automatically during the invoice submission and UPO download operations and can take one of the following values:
-
-
- Not submitted
- Submitted/UPO not received
- Submitted/UPO received
- Rejected
- Date and time of document submission to KSeF and identifier of the Operator who performed the submission
- Date and time of receipt of the document in KSeF, determined after the UPO has been downloaded
- Date and time the UPO was downloaded and the identifier of the Operator who downloaded it
- Session reference number of the invoice submission
- Document reference number, recorded only if the document was submitted in interactive mode
-
The aforementioned tab is available on the forms of the following document types:
-
-
- FS, (s)FS, (S)FS, (A)FS, FSL
- FSE, (s)FSE, (S)FSE, FEL
- RA, RAKFSK, (s)FSK, (S)FSK, (Z)FSK, (A)FSK, KSL
- FKE, (s)FKE, (S)FKE, (Z)FKE, KEL
-
The User can perform the following operations directly from the form of the aforementioned documents. The relevant options available on the right-hand side bar of the [KSeF] tab of the document serve this purpose. These operations are discussed in the further part of this document.
Check correctness in KSeF operation
Submit to KSeF operation
Download UPO operation
On the simplified (A)FS document form, the basic KSeF data is presented in the KSeF section of the [General] tab, and the aforementioned verification/submission to KSeF/UPO download operations are available from each tab of this form. Submission, including serial submission from the VAT Register list, is planned in one of the future versions.
Submitting invoices to KSeF
Submitting documents to KSeF includes the following document types:
-
-
- FS, (s)FS, (S)FS, (A)FS, FSL
- FSE, (s)FSE, (S)FSE, FEL
- RA, RAK
- FSK, (s)FSK, (S)FSK, (Z)FSK, (A)FSK, KSL
- FKE, (s)FKE, (S)FKE, (Z)FKE, KEL
-
Whether the submission is a test submission, aimed only at verifying the correctness of the data entered in the Comarch ERP XL System, the correctness of their interpretation, the correctness of the procedures implemented in the Company, or whether it is the actual entering of the invoice into the business cycle, is determined by the above described setting of the Work environment option on the [KSeF] tab of the System configuration.
Only an Operator with the Submitting invoices/Downloading UPO permission may submit a document to KSeF.
Submitting a document can be done by one of the methods described below.
Automatic submission of invoices during approval
The automatic submission operation is performed if on the definition of this type of document the parameter Automatically during approval is enabled and the document is marked as subject to submission in the Comarch ERP XL system, i.e. the parameter Submit to KSeF is enabled and the parameter Outside the system is disabled. Such submission is carried out both when approving a document from its form and when approving it using the context menu option of the document list, including serial approval of multiple selected documents.
Before a document is approved with automatic submission, the System verifies its date; if the document’s date of issue is different from the current date, an appropriate question/warning is presented.
If the Operator does not have the right to submit invoices to KSeF, then it is not possible to approve a document marked as subject to automatic submission to KSeF, similarly, if the document to be approved does not pass the initial verification of compliance with the e-invoice schema.
Invoice submission from its form
The Submit to KSeF operation is available on the [KSeF] tab of the sales invoices and corrections invoice forms, and on the simplified (A)FS A-vista invoice form on each of them. The button is available provided that all the following conditions are met:
-
-
- The document has been approved (not applicable to A-vista invoices)
- The document is marked as subject to submission in Comarch ERP XL System
- The document has not yet been submitted to KSeF or has been rejected in KSeF
- The Operator has the permission to submit documents to KSeF
-
Serial submission of invoices from the FS/FSE list
The User can submit the invoice using the relevant button under the document list and using the Submit to KSeF option of the context menu of the FS/FSE list, including serially for multiple selected documents.
The aforementioned button under the list of FS/FSE documents is active as long as the cursor is pointing to an approved document and the Operator has the permission to submit documents to KSeF, the other conditions necessary for submitting a document are already checked when the operation is launched. However, the rules for the availability of options in the context menu are identical to those described for the document form button.
Conditions for the effective submission of a document to KSeF
The system performs the submission of the document in question, provided that all the following conditions are met. The fulfilment of some of these determines the availability of the submission option, while some are checked after it has been invoked. Below is a full list of the conditions:
-
-
- The operator has the Submitting invoices/Downloading UPO permission
- Document status: submission applies to documents that have already been approved and have not been cancelled (not applicable to A-vista (A)FS/FSK invoices)
- Document KSeF status: submission applies to documents that have not yet been submitted to KSeF or have been rejected in KSeF
- A document is marked as subject to submission in the Comarch ERP XL System, i.e. the Submit to KSeF parameter is enabled and the Outside the system parameter is disabled
- For manual FSK/FKE corrections – the User has entered the KSeF number of the original – more on this later
- In the case of A-vista (A)FS/FSK invoices, an element or record of the VAT table has been entered on the document
- The document complies with the prerequisites for compliance with the FA(1) scheme
-
The document is only submitted to KSeF if all the above conditions are met. If the initial verification of compliance with the schema is negative, the User is informed and should correct the relevant data either on the document or on related objects such as the Company stamp, counterparty card, address card, commodity card, etc.
A positively verified document is submitted to KSeF. When such a submission is made, the document KSeF status is changed to Submitted/UPO not received and, in addition, the reference number of the session in which it was submitted, the document reference number (for interactive submissions only) and information about the date of submission and the Operator who performed the submission are recorded on the document.
Note: For Multi-branch companies using multiple stamps and VAT IDs, it is important that the User submitting the document is logged in at the centre that registered the document. |
Optionally, an .xml file created from the invoice to be sent can be included as an attachment. More details are provided in the System configuration chapter. This functionality is only available for submissions made in interactive mode.
Invoices submitted to KSeF are available in the taxpayer application provided by the Ministry of Finance at https://ksef-demo.mf.gov.pl/ and https://ksef.mf.gov.pl/.
Each submitted invoice can be viewed and downloaded there.
Data mapping to logical structure of e-invoices according to FA(1) schema
Note: On December 1, 2022, a draft law amending the Value Added Tax Act and certain other acts, concerning the operation of e-invoicing during the period of mandatory use of KseF and a proposal for the next version of the FA(2) e-invoicing schema, was published on the website of the Government Legislation Centre.
The integration with KSeF, introduced in version 2023.0 of the System and described in this document, is based on existing regulations and the FA(1) schema. |
All data submitted by the System to KSeF is established by means of relevant functions/procedures, which can be modified accordingly by the Partners/IT teams to suit the needs of the specific Customer.
Detailed information on how to map data entered in the Comarch ERP XL System to the logical structure of e-invoices will be described in a separate document. This chapter describes only those that require special attention by Users.
Invoice number
A foreign number of document is submitted as the invoice number. The same principle as for JPK_FA, CUK and other declarations has been adopted here. The System behaviour will be parameterised in this respect in one of the future versions and either an own (system) number or a foreign document number will be submitted.
Seller details
The aforementioned data is determined from the stamp assigned to the document, and if the document does not have a stamp assigned, then from the stamp assigned to the main centre of the Company’s structure. The name and address are taken from the [Declarations] and [Declarations cont.] tabs, i.e. according to the rules applicable to JPK_FA and other declarations. On invoice printouts, the Seller details are taken from the [General] tab of the stamp, so Users should ensure that these details are consistent on individual tabs of the stamp. In the case of a Seller who is a natural person, the value from the Name field followed by the first comma is taken as the surname, and the value between the first and second comma of the Name field is taken as the first name.
First and last name of the Purchaser who is a natural person
In the case of a purchaser who is a natural person, the Purchaser’s first and last name is submitted, each in a separate field. As this data is stored in the System in one control/one field, the following rules have been adopted for determining this data: the value from the Name control of the counterparty address form up to the first space is treated as First name, while the value after the first space as Surname. Such mapping is imperfect in the case of unusual data, e.g. the Purchaser’s use of two first names. Therefore, the determination of these data was additionally served on the basis of the attributes named KSEF_Purchaser_FirstName (KSEF_Nabywca_ImiePierwsze), KSEF_Purchaser_Surname (KSEF_Nabywca_Nazwisko) assigned to the document to be submitted. The system first retrieves data from the aforementioned attributes and, if they are not defined, then from the Name field, mapping them according to the aforementioned rules.
The new version of the FA(2) e-invoice schema, published on December 1, 2022, and currently under consultation, provides for the transmission of purchaser data (full name or company name of purchaser) in a single field, so that after its introduction, the aforementioned conventional mapping of purchaser data will no longer be necessary, the data will be taken directly from the Name control.
Purchaser’s address
The e-invoice scheme envisages submitting data on the street, house number and apartment number in separate lines, while in Comarch ERP XL these data are saved in one field of the counterparty’s address form. An appropriate function is used to map address data, extracting the street, house number and apartment number from the entire contents of the address field. This function is not perfect, e.g. in cases where the street name contains digits, and in the case of localities where streets are not distinguished. To enable Users to handle such specific cases, additional identification of the above address components based on the relevant attributes assigned to the document header is supported: KSEF_Purchaser_Street (KSEF_Nabywca_Ulica) (including with the value None, which means that the street name is to be left blank), KSEF_Purchaser_HomeNumber (KSEF_Nabywca_NrDomu), KSEF_Purchaser_ApartmentNumber (KSEF_Nabywca_NrLokalu). The System first retrieves data from the aforementioned attributes and, if they are not defined, then from the Street field, mapping them according to the aforementioned rules
The aforementioned additional mapping of data from the System to the e-invoice schema will no longer be necessary if the planned FA(2) schema comes into force, according to which all Purchaser address data will be sent in one field.
Elements-commodities on the invoice
Whether the System will submit to KSeF the quantity and price for the primary or secondary unit of a transaction element is determined by the applicable option in the System configuration, discussed earlier in this document.
Note: The FA(1) e-invoice schema does not provide for the possibility of submitting the price with 4 decimal places, so it is rounded to 2 decimal places during submission. In the planned FA(2) schema, this inconvenience will no longer exist. |
The section containing information on the form and date of payment and the Seller’s bank account will be handled in one of the future versions
Additional information can be included in the Description of either the invoice header or its elements and/or in the footer assigned to the document definition. The description from the header is always submitted, whereas the description of the document element is submitted if the Element description parameter is enabled in Configuration/KSEF/Submit during export
Clips containing corrections for commodity returns vs. KSeF
Users using KSeF should avoid clipping to the (S)FS/FSE/RA documents of the WZK/WKE/PAK other than a quantitative plus correction, as the System does not perform any grouping of elements, but submits each of them separately, which in the case of the aforementioned clipped corrections means sending a zero or negative element quantity. For such WZK/WKE/PAK, it is recommended to register (S)FSK/FKE/RAK or, for such cases, to register the (s)FS, (s)FSE elements clip instead of the header clip.
Correction of a counterparty/counterparty’s VAT ID (NIP)
According to the explanatory notes to the schema, an invoice to the wrong counterparty (or a mistake in its VAT ID (NIP)) should not be recorded and sent as a data correction, an overall correction and a new invoice should be issued.
Downloading an official acknowledgement of receipt – UPO
The User obtains certainty and confirmation that the invoice has actually been received in the KSeF System upon receipt of the UPO. The KSeF number of the document is then recorded on the invoice and the status of the document is changed to Submitted/UPO received.
UPO can only be downloaded by the Operator with the Submitting invoices/Downloading UPO permission, and this can be performed by one of the methods described below.
Downloading UPO from the document form
The Download UPO operation is available on the [KSeF] tab of the sales invoice and sales invoice correction forms, and on the simplified (A)FS A-vista invoice form on each of them. The button is available provided that the following conditions are met:
-
-
- The document has been submitted to KSeF and no UPO has been downloaded for it yet
- The Operator is authorised to download UPO
-
The UPO is downloaded in the KSeF session context within which the document was submitted. It is downloaded sequentially for all documents submitted within this session. Thus, even if the UPO download operation is invoked from the document form, the System will download the UPO not only for this document, but also for other documents submitted in this session, as illustrated by the second figure below.
Once the UPO has been downloaded, the System records the following data on the invoice(s) to which the UPO relates:
Document KSeF number
Date of receipt by KSeF
Date on which the UPO was downloaded and the identifier of the Operator who performed the download
The document KSeF status is set to Submitted/UPO received
Optionally, the .xml file of the downloaded UPO can be included as an invoice attachment. More details are provided in the System configuration chapter.
Downloading UPO from FS/FSE list
The User can download UPO using the relevant button under the document list and using the Download UPO option of the context menu of the FS/FSE list, including serially for multiple selected documents.
The aforementioned option in the context menu remains active if the cursor points to a document with a status of Submitted/UPO received and the Operator is authorised to download UPO. The activity of the option next to the button, on the other hand, is conditioned by the abovementioned Operator’s permission and the status of the document (document approved), the document KSeF status is verified after the operation has been triggered.
As already mentioned above, the UPO is downloaded in the context of a specific KSeF session, i.e. for all documents submitted within that session. The operation of downloading UPO from the list of documents, including for multiple marked documents, therefore consists of downloading the UPO for the documents submitted within those sessions to which the marked documents point. Thus, it may happen, for example, that the User selects several documents, but the UPO is downloaded for more than a dozen. The User is informed of each document for which UPO has been downloaded.
Downloading UPO for current KSeF session
UPO can also be downloaded for the User’s current KSeF session, i.e. all documents that have been submitted within this session. This is done using the Download UPO button of the form available in the System/KSeF session menu.
Invoice validation according to KSeF schema
The Check correctness in KSeF operation consists of checking the semantic correctness of the document, i.e. compliance with the e-invoice schema.
With this functionality, the User is able to verify the document before it is approved.
The aforementioned functionality is available on sales invoice forms and sales correction forms, as well as in the context menu of the FS/FSE list.
Automatic document validation according to the KSeF schema during document approval is also supported. This is done if the document is marked as subject to submission and the Verify in KSeF before approval parameter has been activated on the document definition.
If the document validation is successful, then document approval continues; in the event of a negative validation, document approval is not possible.
As part of the aforementioned document validation, the System checks the date of the document; if the document’s date of issue is different from the current date, an appropriate question/warning is presented.
KSeF information in the invoice list
In the list of commercial documents, new columns with information on KSeF integration have been made available on the [FA] and [FSE] tabs: Status, Number, Date of submission.
Documents can take one of the following KSeF statuses:
Not applicable. Invoices that are marked as not subject to submission to KSeF receive this status.
Not submitted. This is the status of documents marked for submission that have not yet been submitted.
Submitted/UPO not received is the status of a document submitted to KSeF for which UPO has not yet been downloaded.
Submitted/UPO received is the status of a document submitted to KSeF for which UPO has been downloaded.
Rejected. This status is given to documents that have been sent to KSeF but have been rejected by KSeF.
A filter has been made available to restrict the list of documents by KSeF Status. The filter provides the aforementioned values and, in addition, the value Submitted, which includes all documents that have been submitted regardless of whether UPO has already been downloaded for them or is yet to be downloaded.
KSeF number of the original on manual correction
On the form of manual correction of FSK/(A)FSK/FKE, a control has been made available which allows the User to enter the KSeF number of the original, registered outside the Comarch ERP XL System. On a non-approved document, this number can be entered by any Operator with the permission to edit that document, whereas once a document has been approved, an Operator with the Editing KSeF number on documents permission can do so. The editing of the control is blocked once the document has been submitted to KSeF.
Document KSeF number on printouts of sales invoices and their corrections
An invoice submitted to KSeF can only be considered to have been successfully issued once the UPO for it has been received and the number assigned to that invoice has been received in KSeF. From the publications to date, including answers to the most common questions available on the Ministry of Finance’s website https://www.podatki.gov.pl/ksef/pytania-i-odpowiedzi-ksef/, it appears that submitting an invoice via the KSeF System does not mean that it cannot also be submitted to the Purchaser in the traditional way, either on paper or electronically, through the channels that entities have used so far. However, the sequence of operations is crucial, i.e. the traditional transmission of the invoice to the Customer should take place after the KSeF number has been assigned to the invoice, as only then can the invoice be regarded as having been issued and only then does it enter into economic circulation. Perhaps the above-mentioned rules will be changed once the KSeF System becomes mandatory.
The Comarch ERP XL System does not provide for any form of blocking of invoice printing or warning against such printing, it is up to the Users to adopt appropriate procedures for sending/printing invoices.
To make it easier to implement/comply with the above procedures, optional printing of the document KSeF number has been supported on sales invoice printouts and their corrections. Whether such a number is to be printed is determined by the setting of the Print document KSeF number parameter in the print parameters window. This parameter is available if the Company submits to the KSeF production server.
The printing of the KSeF number is supported on the basic printouts available for the following document types:
-
-
- FS, (s)FS, (S)FS, (A)FS, RA
- FSE, (s)FSE, (S)FSE
- FSL advance invoices, FEL
- Final invoices: FS, (s)FS, (S)FS, FSE, (s)FSE, (S)FSE
- Corrections to the above documents, with the exception of manual corrections, collective corrections, and data corrections
-
Restriction on editing a document submitted to KSeF
-
-
- Documents submitted to the KSeF production environment cannot be cancelled and A-vista documents cannot be deleted. The system blocks such an operation with a corresponding message:
-
-
-
- Previously, an authorised User could change the below mentioned data on approved sales documents. This data is part of the information submitted to KSeF and, therefore, if a document has been submitted to the KSeF production environment, it can no longer be edited. This data is:
- Sale date
- Document foreign number
- Address of the main counterparty/target counterparty/payer
Documents recorded in the Retail (Detal) application vs. KSeF
The KSeF integration functionalities described above are not available in the Retail application. Regardless of the document definition, there is also no validation of the KSeF or automatic submission of the document. Documents recorded in Retail should be submitted to KSeF from the Sales module.
Emergency mode for recording invoices
The draft act amending the Goods and Services Tax Act and certain other acts, published on December 1, 2022, concerning the operation of e-invoicing during the period of mandatory use of KSeF provides for the following rules for dealing with KSeF system failures and other special situations:
-
-
- Inaccessibility of the KSeF related to the maintenance of this system
-
Taxpayers are to be informed in advance of planned maintenance work and the associated unavailability of KSeF. The system unavailability is expected to be short-term. No invoices or correction invoices will be issued during this period.
-
-
- KSeF failure
-
Information about the KSeF failure will also be published with messages on the MF BIP. During the failure period, the taxpayer will use the same invoice template that will be widely used after the implementation of mandatory e-invoicing. The invoice template filled in by the taxpayer, together with the invoice date entered in field P_1, will constitute a fully-fledged invoice, which the taxpayer is then obliged to pass on to the purchaser in the manner agreed therewith. Following the KSeF failure, invoices issued during this period will be required to be submitted by the issuer to KSeF within 7 days of the end of the KSeF failure.
-
-
- Events not related to system failure – emergencies
-
In the aforementioned situations, correction invoices/invoices can be issued and delivered to purchasers according to the existing rules, i.e. in paper or electronic form.
Further plans for integration with KSeF
Further development of the KSeF integration functionality is planned for future versions of the System, including:
-
-
- Development of the submission mechanism:
- Submission of documents from the VAT Register
- Provision of an external API for submission
- Successive handling of optional information in KSeF submission
- Import of purchase invoices from KSeF
-
Other changes
New columns in the lists of commercial and import documents
The list of commercial and import documents has been enriched with new columns. They are hidden by default, so if the User wishes to use them they should enable them on the list form they are using.
Note: Due to the changes made in version 2023.0 to the lists of commercial and import documents, Users who use their own columns should change their position according to their own preferences after converting the database, as their own columns will be placed at the end of the list of columns by default. |
VAT ID (NIP) [Prefix] and [VAT ID] number of the main counterparty
The aforementioned columns have been made available on all those lists of TraNag and ImpNag documents where the counterparty is presented.
VAT ID (NIP) [Prefix] and [VAT ID] number of the target counterparty
The aforementioned columns have been made available in all those lists of TraNag and ImpNag documents where the target counterparty is presented, provided that the presentation of the target counterparty is enabled in the Configuration
[Foreign number] of the document
The aforementioned column has been made available in the lists of sales documents: FS, FW, WZ, FSE, WZE, WKA and is filled in with the value entered in the Invoice control of the sales document form. For the aforementioned document types, this control defaults to the document’s system number, so this column will be useful for those Users who change this number, e.g. accounting offices.
The aforementioned column is not available in the lists of purchase documents, as its role is largely fulfilled by the current Source column.
The [VAT] value of the document
The aforementioned column has been made available on lists of those commercial documents the value of which presented in the list is always expressed in the system currency, i.e. on documents other than export/import documents.
[Sale date]
Up to now, the sale date was not presented in the FSE and WZE document lists; in version 2023.0, it has also been made available for these lists. For FSE/WZE documents, it is filled in with the sale date and for corrections with the date of correction.
[Date of issue]
The date of issue has been made available on the lists of FZ, PZ, PKA and FAI documents, where it was not previously present.
[Date of purchase]
The date of purchase has been made available on the lists of FZ, PZ, FRR and FAI documents, where it was not previously present. For FZ, PZ, FRR, and FAI documents, it is filled in with the date of purchase and for corrections with the date of correction.
Once available, the columns described above are available in the lists shown in the table below. The columns and lists supported in version 2023.0 are highlighted in colour
List | Main counterparty | Target counterparty | Foreign number | VAT | Sale date | Date of issue | Date of purchase | ||
Prefix | VAT ID (NIP) | Prefix | VAT ID (NIP) | ||||||
FZ | + | + | + | + | – | + | – | + | + |
PZ | + | + | + | + | – | + | – | + | + |
FRR | + | + | + | + | – | + | – | + | + |
FAI | + | + | + | + | – | – | – | + | + |
FS | + | + | + | + | + | + | + | + | – |
FW | + | + | + | + | + | + | + | + | – |
WZ | + | + | + | + | + | + | + | + | – |
PA | + | + | + | + | – | + | + | + | – |
TF | + | + | + | + | – | – | – | + | – |
KK | + | + | + | + | – | + | + | – | |
FSE | + | + | + | + | + | – | + | + | – |
WZE | + | + | + | + | + | – | + | + | – |
WKA | + | + | + | + | + | – | – | + | – |
PKA | + | + | + | + | – | – | – | + | – |
PW | + | + | + | + | – | – | – | + | – |
RW | + | + | + | + | – | – | – | + | – |
Determination of prices and values on the copied offer and order
Version 2023.0 tidies up the rules for establishing prices and values on the elements of offers and orders resulting from the operations listed below, as the System has so far behaved inconsistently in this regard:
-
-
- copying an element of an offer/order
- copying the entire offer/order document
- creating an offer variant
-
The following rules apply when carrying out the above operations:
-
-
- The type of initial price (OS, ZS) is determined by the item being copied
- The level of initial price (OS, ZS, OZ, ZZ) is determined by the item being copied
- The final price and the final value are determined depending on the discount method used by the User
- In the case of discounts calculated from the price (enabled Discounts calculated from price parameter in Configuration/Sales/Discounts and special offers), the final price is copied from the source item, while the value of the item and the discount are calculated on the basis of the initial price, the final price and the quantity, so they can be different from those on the item being copied
- In the case of discounts calculated from value (the aforementioned parameter is deactivated), the final value is copied from the source item, while the price and the discount are calculated based on the initial value, the final value and the quantity, so they may be different from those on the item being copied
-
Address details and contact person on the Parcel document
On the Parcel document, the [General] tab presents the address and contact details that are assigned thereto. Until now, only the acronym of the associated address was displayed.
The address on the parcel is set on the basis of the documents linked thereto, provided that the Check conformity of delivery address of parcel documents parameter is selected in the configuration of the Configuration/Sales/Parameters 2 module.
As of version 2023.0, this setting also determines whether counterparty is added to the parcel. The person is selected automatically on the basis of the related documents. This can also be done independently by selecting the relevant record from the list of persons assigned to the counterparty.
Currently, when an address is retrieved for a parcel from related documents (always from the [Target counterparty] tab) and counterparty is filled in on these documents (on the same tab), then this is also retrieved for the parcel. Since a different person may be set on each document, the method of retrieval is as follows:
-
-
- When parcels are created, the person in the document list is taken from the first document in the queue on which it is completed.
- When attaching documents to parcels, the person is also taken from the first document in the queue on which it is completed. Here, it may not be retrieved if the person on the parcel is already completed.
-
When deleting a document link to a parcel, the person is not modified until the last linked document is deleted. This is because the address and hence the contact person is removed from the parcel.
As long as the Parcel document is not approved, the counterparty can also be completed, deleted or modified on its own by selecting any person from the list of all counterparty persons. It is only important that any document is linked beforehand, on the basis of which the counterparty for the parcel is established.
Along with establishing a contact person, their contact details can also be retrieved on the parcel: telephone and e-mail. This is of particular relevance to the collaboration with Comarch Shipping, which is covered in more details in the chapter with the same title.
By default, the data from the address associated with the parcel were treated as contact details for the parcel. Now, with the appropriate setting in the configuration of the Sales module (Configuration/Sales/Parameters 2) of the new Contact details on the parcel from the counterparty parameter, it can be made to be retrieved from the contact person on the parcel, if one is selected on the parcel. Then the contents in the Phone and Email controls are replaced immediately on the parcel, so we can see directly which contact details are valid for the parcel.
Including commodities inventoried on stock documents – blocking
The following operations were blocked on AWD/ZWM and (W)AWD/(W)ZWM documents that had items added for commodities subject to inventory:
-
-
- Blocking of submission of a document for execution (unchecking the To buffer parameter)
- Blocking the closing of a document (unchecking the Closed parameter).
-
When generating such documents, it is also necessary to check that the source items are not for commodities that are currently subject to inventory. If they are, then such items will not be added to the stock document.
Ergonomics of operations on agreements
Taking into account users’ demands for agreements, the following improvements have been made:
-
-
- Copying of conclusion and completion dates when copying an agreement. It does not matter if the dates from the source agreement are earlier or later than the current date, they will always be transferred to the new agreement.
- Removal of selected items from the agreement.
-
CRM
On the Commodity delivery route form, the ability to add waypoints in series has been added. A drop-down menu with two options is available next to the Plus button: Add point and Add list.
Command to add waypoints in series
The Add point command allows you to add a single point by filling in the waypoint form (action as before for “plus”).
The Add list command invokes a list of counterparties in selectable mode, where multiple records can be selected. Once the selection is accepted, the counterparties are added as further waypoints and the counterparty’s current address is set as the address.
Archived counterparties and those already added as a point for this route (provided they have been added with a current address) are not included in the serial addition. The rules for adding points in a serial operation are therefore the same as for adding a single waypoint.
Production
Pausing the execution of launched operations
It has been made possible to pause an operation, i.e. to stop and resume the running execution of a production order operation. Thus, in the event that work on an operation is to be temporarily halted, a pause can be recorded and the duration of such a pause will not be included in the duration of the operation and optionally may also not be included in the settlement time of the completed operation.
List of Pauses in the Operation execution window
In the Operation execution window on the [General] tab, a Pauses section has been added to display all pauses added for execution. From the pauses list, the User can add a new pause (when the operation is not currently paused), end a pause (when the operation is currently paused), and edit or delete a pause.
The pause list, in the operation execution window, is made up of the following columns:
-
-
- Start – the column shows the pause start date (date and time)
- End – the column shows the pause end date (date and time)
- Time [unit] – the column shows the duration of the pause, in the same unit as set for the operation execution time
- Settlement time [unit] – the column shows the pause settlement time, in the same unit as set for the operation execution time
- Pause reason – the column shows the pause reason
- Added by – the column displays an identifier of the operator who added the pause
- Added – the column displays the date the pause was added, together with the time
-
In the list of pauses, the following options were made available in the operation execution window:
-
-
- Enable/disable summing – this option can be used to enable or disable summing up in the list
- Pause – this option adds a pause (stopping the operation). Button available when no pause is currently in progress for the operation, otherwise the Resume button is available instead
- Resume – the option is used to add an end to the pause (resumption of the operation). Button available when no pause is currently in progress for the operation, otherwise the Pause button is available instead
- Change – this option can be used to edit the indicated pause. The pause is edited using the edit-in-place method, in the pause record
- Delete – this option can be used to delete the indicated pause
-
Note: From the Operation execution window, a pause can also be added on a completed operation execution, whereby it is added immediately as completed, i.e. with the Start and End dates completed, for which the current date is prompted.
From all other locations in the system, it is possible to pause and resume only running operation executions. |
On the completed execution of an operation, where pauses are added to it, the duration of the pause and the settlement time of the pause are deducted from the aggregate execution time and the settlement time, to the extent that it falls within the operation dates.
Example: The operation was carried out between 8:00 a.m. and 1:00 p.m., i.e. the execution and settlement time of the deadline is equal to 5 hours. During the operation, two pauses were recorded: the first from 10:00 to 10:15 (with a duration and settlement time of 0.25 hours) and the second from 12:30 to 12:45 (with a duration and settlement time of 0.25 hours). The aggregate execution and settlement time of the operation is calculated as 4.5 hours, as 0.5 hours of the execution and settlement time of both pauses are subtracted from the 5 hours of the execution and settlement time of the operation. |
Note: When the pause term is only partly contained in the execution deadline of the operation, only that part of the duration will be deducted from the execution and settlement time of the operation and the proportionally calculated part of the settlement time of the pause that is contained in the execution duration. |
Pausing and resuming a running operation from lists
The pause can be added or ended from the Operation execution window (3.1.1). In addition, a pause can be added or ended with a new dedicated Pause or Resume button available by highlighting a running execution with the corresponding status (if the running execution does not have a pause in progress then the Pause button is available, and if a pause is currently in progress for it then the Resume button is available) from the level of:
-
-
- Production order window, from the [Processes] tab
-
New dictionary: Pause reasons
For the purposes of the above functionality, a new dictionary has been added in the Administrator module, under Lists/Category dictionaries/Production: Pause reasons. Predefined values have been added to this dictionary: Machine failure and Employee break. In addition, the User can define own values to indicate for the pause to be recorded.
Parameterisation of the automatic calculation of the pause settlement time, which reduces the settlement time of the operation execution
In the Edit company structure window, on the [Production 2] tab, a new parameter has been added: Pause reduces the execution settlement time.
With the Pause reduces the execution settlement time parameter selected, adding the end for a pause will automatically calculate the pause settlement time based on the duration of the pause and the ratio of execution time to operation settlement time set on the technology.
If the Pause reduces the execution settlement time parameter is unselected, when adding the end for a pause, the pause settlement time will be 0.
Note: Regardless of the setting of the Pause reduces the execution settlement time parameter, at the end of a pause the User will always be able to manually modify the pause settlement time and if this time is greater than 0 it will be deducted from the execution settlement time, as long as the pause date is within the operation execution date in whole or in part. |
Statuses of operation execution
Until now, statuses were only given to planned operations. With the addition of the pause functionality for operations, the assigning and displaying of statuses has also been supported for operation execution.
In the case of triggered executions, they may be given the following statuses: In progress (if the running execution has no pause in progress i.e. no pause has been added or all pauses are ended) or Paused (if the running execution has a pause currently in progress i.e. has a pause added that has not yet been completed). In contrast, completed executions will always have a status: Completed.
Based on the status, different icons are also displayed for executions in various lists. Until now, there were two icons: for running (currently displayed for executions with status In progress) and for completed executions (currently displayed for executions with the status Completed). In this version, a third icon has been added for paused running executions (for executions with the status Paused).
Operation execution statuses are displayed in the following locations:
-
-
- In the header of the Operation execution window
-
New filters in the Operations schedule window
In connection with the handling of statuses for operation executions, filters have been added to the Operations schedule window, allowing the list of operations to be narrowed down to executions with a specific status. Under the existing filter: Operation executions responsible for displaying the execution in the list, sub options have been added:
-
-
- In progress – when this option is selected, the list displays executions with the status In progress
- Paused – when this option is selected, the list displays executions with the status Paused
- Completed – when this option is selected, the list displays executions with the status Completed
-
Due to the addition of new filters, the arrangement of the existing filters has been partly changed.
Expansion of the Status filter in the Change or add resources window
In connection with the handling of statuses for operation executions, new options have been added to the Status filter in the Change or add resources window: In progress, Paused and Completed, allowing the list of operations to be narrowed down for execution with a particular status.
The operation of the existing options has also been modified: Started, In execution and Completed, which previously searched for all planned operations with the indicated status and their executions, but now only searches for planned operations with the given status (without their executions).
Calculation of cost for any quantity of product
From version 2023.0 of Comarch ERP XL system, it is possible to recalculate cost calculations for any quantity of a product from a technology.
New options and parameters in KLK
New fields have been added to the cost calculation where it is possible to indicate for which quantity and which product from a given technology the calculation is to be recalculated.
In the field: you can specify the quantity of the product for recalculation. This quantity is expressed in the basic unit of the product.
In the field, you can indicate the product, for which recalculation will be performed. The product can be selected from the technology already loaded onto the KLK document.
It will be possible to change the product on the KLK document when this document is generated or added on the basis of a technology or ZP. If the KLK is created on the basis of a ZS, OS, ZW document, it will not be possible to change the product and product quantity thereon.
To indicate on the KLK the product for which the recalculation is to be performed, press the button and then select the relevant product from the open product list of the technology in question.
Next to the fields for entering the product code and name on the KLK document, there is a Recalculate button that can be used to perform recalculation for any quantity of the selected product.
New columns on KLK
New columns have been provided on KLK to show the quantity of materials and products, expressed in the auxiliary unit.
Recalculation of KLK for any quantity of product
The first opening/reading of the KLK should work as before. For the default loaded quantity, the corresponding cost of the products should be calculated. Subsequent recalculation of the KLK document using the new Recalculate button or using the existing Recalculate report using the selected simulation/rate options will recalculate the KLK for the selected product and the quantity specified for it, taking into account other current parameter settings found on the KLK. Individual quantities and costs will be calculated on the basis of the indicated technology in proportion to the quantity of product stated on the KLK.
When recalculating the KLK, the minimum quantities specified in the technology will not be taken into account.
Other changes to KLK
-
-
- Product cost area
-
A new area has been introduced on the KLK document in which the calculated value of the product and its unit cost is presented.
In the field For calculated quantity: the product cost is presented, which is also visible in the column: Simulated cost/Cost. In the Unit field, on the other hand, the product’s unit cost is presented (e.g. cost of 1 item), which is also visible in the Simulated cost/Price column.
-
-
- Show zero costs parameter
-
An option has also been made available with which zero prices or costs can be highlighted on KLK.
If the Show zero costs parameter is selected, zero costs and prices will be highlighted on the calculation. These will be displayed in red on the document.
New columns have been added to the KLK list to show the code and name of the product to which the KLK document relates.
Other changes
Starting and stopping operations in the Operations schedule window
Dedicated buttons have been added to the Operations schedule window: Start term execution with options to start operations and Execute term with options to add operation execution. These are the same functions as, among others, in the Production order window, on the [Processes] tab, for starting or executing a planned operation highlighted in the list.
Within the options under the button to start operations, the following options are available:
-
-
- Start operation
- Start operation without editing
- Start term execution
- Start term execution without editing
- Start remaining
- Start remaining without editing
-
Within the options under the button to execute operations, the following options are available:
-
-
- Execute term
- Execute stage
- Execute all
- Execute term without editing
- Execute all without editing
- Execute remaining
- Execute remaining without editing
-
In the same way as for the same buttons available in the Production order window, among others, on the [Processes] tab, the settings selected in the listed fields determine which option is activated by default directly under the button to start or execute operations: Default execution start and Default execution completion on the Production order document definition, on the [Production] tab.
Accounting
VIU-DO declaration
New parameters on sales invoices
The news document prepared for Comarch ERP XL 2022.1 describes new parameters, introduced on sales invoices, on the [VAT] tab for the VIU-DO declaration.
Changes to the company stamp
In the company stamp, a field called VIU-DO (OSS) has been introduced on the [Declarations] tab. In this field, indicate the tax office which is the addressee of the VIU-DO declaration. The office entered here will automatically appear on the VIU-DO declaration form.
VIU-DO declaration form
Location of the VIU-DO declaration
In Comarch ERP XL 2023.0 version, the VIU-DO declaration form has been made available in the Ribbon, Declarations/VIU-DO menu.
To view the VIU-DO declaration and to add a new form, select VIU-DO. In the Tax returns window, the list will be narrowed down to VIU-DO declarations only.
Structure of the VIU-DO declaration form
The VIU-DO declaration form consists of the following tabs:
General
Header
Exchange rates
Declaration
Record
Additional record
Payments
Accounting
Attachments
In a nutshell, the VIU-DO declaration form comprises a declarative and a record part.
-
-
- The declarative part is the equivalent of the VIU-DO declaration, on the basis of which an xml file is generated for submission to the Ministry of Finance’s e-Declarations (e-Deklaracje) gateway.
- The record part consists of two parts, from the tab level:
-
Record – the documents that are the source of the generation of the various sections on the VIU-DO declaration are presented
Additional record – for invoices listed on the Record tab, information on sold commodities, provided services is additionally presented
The export of data to Excel from both records should facilitate the taxpayer’s preparation of the records referred to in the Vat Act, Article 130 and Article 63c of the EU Council Implementing Regulation 2019/2026.
The records are not subject to submission to the Ministry of Finance’s e-Declarations (e-Deklaracje) gateway.
VIU-DO declaration statuses
In accordance with the adopted standard, four statuses were made available on the VIU-DO declaration:
-
-
- Buffer
-
Full data editing
Ability to calculate declarations – active Recalculate button
Possibility of trackless deletion of declarations
Possibility to submit draft declarations
No possibility to submit declarations in the final version (Submission)
-
-
- Accepted
-
No possibility to calculate declarations – inactive Recalculate button
Editing limited to [Payments], [Accounting], [Attachments] tabs
Possibility to submit draft declarations
Possibility to submit declarations in the final version (Submission)
No change of status to approved after submitting a declaration in draft version, upon receipt of a valid UPO
After sending the final declaration as Submission and receiving the correct UPO, automatic change of the status to Approved
-
-
- Confirmed
-
No possibility to calculate declarations – inactive Recalculate button
Editing limited to [Payments], [Accounting], [Attachments] tabs
Possibility to submit draft declarations
Possibility to submit declarations in the final version (Submission)
-
-
- Cancelled
-
According to the adopted standard, possibility to cancel a declaration with the status Approved
Rules, way of cancelling the VIU-DO declaration form analogous to e.g. JPK_V7 files
No possibility to submit draft and final declarations
VIU-DO declaration form – “General” tab
On the General tab, the following data is available:
-
-
- In the Period section, the accounting year, quarter, which is suggested by default based on the year, quarter set in the list of declarations
- In the Number field – the sequence number of the form.
- In the Version field – the structure’s version number.
- In the Status field in selectable mode, options:
-
Buffer – default status
Accepted
Approved
Cancelled – status available on approved form
-
-
- In the Office field – the office indicated in the company stamp – see section on changes to the company stamp for details
- In the Entered by field – the code of the operator adding the form for the first time
- In the Modified by field – the code of the operator modifying the form
- In the Approved by field – the code of the operator approving the form
- In the Submitted by – the code of the operator, who submitted the form
- In the E-declaration verification, e-declaration status fields, depending on the type of submission, the information status
-
If the declaration is submitted as a draft and there is no verification information:
Field | Information type |
e-Declaration (e-Deklaracja) verification | In progress |
e-Declaration status | Draft version |
If the declaration is submitted as draft and verification is correct:
Field | Information type |
e-Declaration (e-Deklaracja) verification | Correct |
e-Declaration status | Draft version |
If the declaration is submitted as draft and verification is negative:
Field | Information type |
e-Declaration (e-Deklaracja) verification | Negative |
e-Declaration status | Draft version |
If the declaration is immediately sent as a submission, enter None in the e-Declaration Verification field. Type of information displayed in the e-Declaration Status field analogous to JPK_V7
Field | Information type |
e-Declaration (e-Deklaracja) verification | None |
e-Declaration status | According to the standard adopted on JPK_V7 |
Analogously to the JPK_V7 file form, the following fields are also presented:
-
-
- Reference number
- Registration date
- Confirmation date.
- URL
- Notes
-
A new feature is the UNR field. In this field, enter the unique reference number that the taxpayer receives when the declaration is submitted. The value of this field should be used in the title of the transfer. An example UNR for the EU OSS procedure is: PL/PLXXXXXXX/Q3.2022
More information here: https://www.podatki.gov.pl/vat/wyjasnienia/rozliczanie-podatku-vat-w-ramach-procedury-unijnej-oraz-nieunijnej-oss-i-procedury-importu-ioss/
VIU-DO declaration form – “Header ” tab
The [Header] tab contains the following data:
-
-
- In the Form section:
-
System code – “VIU-DO (1)”
Tax code – “VIU”
Liability type – “Z”
Schema version – “1-0E”
Form version – “1”
-
-
- Completion date – in this field, when the Recalculate button is selected, the current date is set, unless the current date is earlier than the date of the last day of the accounting quarter. In this case, the system will set the date of the last billing quarter + 1 day. This is evident from the explanation in the schema, which reads:… “The date of submission of the declaration or correction to the system must be no earlier than the day after the end of the quarter to which the declaration relates and no later than 3 years after the submission deadline”.
- Entity
-
If a non-natural person is selected in the company stamp, the following fields are made available on the form:
-
-
-
- VAT ID (NIP)
- Full name
- Phone
-
-
If a natural person is selected in the company stamp, the following fields are made available on the form:
VIU-DO declaration form – “Exchange rates ” tab
Transaction amounts on the VIU-DO declaration (Net, VAT) are expressed in Euros and are not subject to rounding.
If payments for the supply of goods or services were made in currencies other than Euro, the exchange rate published by the European Central Bank (ECB) on the last day of the relevant accounting period, or if not published on that day, the exchange rate published on the following day, shall be used for their conversion into Euro.
From the [Exchange rates] tab, it is now possible to enter exchange rates for transactions expressed in currencies other than Euro. It features:
-
-
- Editing parameters parameter. Selecting this activates fields which allow to enter rates of exchange to Euro for the eight currencies of the countries which have not joined the Monetary Union
- fields for entering exchange rates. As there are no mechanisms to automatically convert one foreign currency into another, a 1:1 exchange rate is suggested by default. Fields where a rate change occurs are displayed in yellow until the form is recalculated. Conversion results in the validation of exchange rates and the conversion of amounts expressed in currencies other than Euro into Euro.
- date fields next to rate fields. By default, the date of the last day of the settlement period is suggested
- Description field, which allows you to enter your own notes, e.g. on exchange rates.
-
Note: If there are WSTO_EE transactions qualified for inclusion on the VIU-DO declaration, the amounts of which are expressed in currencies other than Euro and in currencies other than those made available on the currencies tab (e.g. USD), the system will refer to the amounts expressed in PLN and convert them at the exchange rate indicated for PLN. |
VIU-DO declaration form – “Declaration” tab
VAT table items are included on the VIU-DO declaration linked to documents on which the OSS Procedure parameter has been selected and the Do not include on VIU-DO declaration parameter has not been selected.
The OSS Procedure parameter is available on documents with the WSTO_EE transaction type selected.
The aforementioned parameters, pre-select the items of the VAT table for inclusion on the VIU-DO form, in the record and declarative parts.
The VIU-DO declaration contains seven sections; C.1 to C.7, with the VAT table items directly affecting the generation of items in three sections: C.2., C.3., C.5. In the other sections, they are processed, summed up according to the logic imposed by the schema.
The name of the tab is linked to the sections of the VIU-DO declaration visible on the tab.
For C.2, C.3 and C.5 sections, in addition to the presentation of subsections related to the section, it was made possible to narrow down the subsections to a particular country of consumption. This way of presenting data is made possible by providing two windows under the buttons: Countries, Section “C…”
In the Section window, using the Display all button, it is also possible to display all subsections regardless of the country of consumption.
VIU-DO declaration form – “Record” tab
Two windows are made available on the Record tab:
By declaration section
Sales details
“Record” tab, “By declaration section” window
The By declaration section window presents the aggregates corresponding to the individual subsections associated with sections C.2, C.3, C.5.
The information displayed in the individual columns is limited to the data displayed within the particular section of the VIU-DO form to which the VAT table entry is assigned. Therefore, there will be differences in the presentation of the data assigned to sections C.2, C.3 and C.5.
For data linked to section C.2, information on Country of consumption, Type of delivery, and Rate is presented. For data linked to section C.3, information on the country of issue is additionally presented.
The columns Net EUR, VAT EUR present the total net and VAT amounts in Euro, calculated on the basis of the amounts of the items assigned to the subsection concerned, presented in the Sales details window.
“Record” tab, “Sales details” window
In the Sales details window, it is now possible to display the items of the VAT table qualified for VIU-DO declaration.
-
-
- The display of VAT table items can be narrowed down to a particular subsection or all items can be displayed using the Display all button.
- In the list, in addition to the basic data identifying the document to which the displayed VAT table item is linked, the number of the subsection to which the VAT table item has been qualified is also presented. Multiple VAT table items may be associated with a given subsection.
- The Net column shows the net amounts in the currency of the transaction. The currency identifier is presented in the Currency column.
- The Net EUR column shows net amounts converted into Euro, whereby if the currency of the transaction is:
Euro, the amount from the Net column will be rewritten to the Net EUR column
a currency other than Euro, but included in the set of currencies made available on the Exchange rates tab, the amount in the Net column will be converted into Euro at the rate indicated for that currency on the Exchange rates tab and presented in the Net EUR column
a currency other than Euro, not included in the set of currencies made available on the Exchange rates tab, an amount in PLN will be presented in the Net column, which will then be converted into Euro at the rate indicated for PLN on the [Exchange rates] tab and presented in the Net EUR column.
-
-
- The VAT EUR column shows the VAT amounts calculated on the basis of the amounts shown in the Net EUR column using the rates shown in the Rate column.
-
Note: On the Declaration tab, VAT amounts in Euro are calculated on the basis of the total net amounts in Euro, presented per subsection using the relevant VAT rate.
On the Record tab, within the aggregates corresponding to each subsection, VAT amounts are presented, which are the sum of the VAT amounts of the items assigned to the section. |
“Additional record” tab
Three windows are made available on the [Additional record] tab:
By consumption country
Invoices
Commodities/Services
“Additional record” tab, “By consumption country” window
In the By consumption country window, the consumption countries associated with sales invoices the VAT table items of which are qualified for VIU-DO declaration are presented.
“Additional record” tab, “Invoices” window
In the Invoices window, it is now possible to present all invoices as well as limited to a particular country of consumption.
The list displays invoices that contain at least one VAT table item qualified for a particular VIU-DO declaration.
Most of the invoice identification data displayed on the [Record] and [Additional record] tabs overlap.
On the [Additional record] tab, the purchaser’s address and consignment number are presented. This data is not presented on the [Record] tab.
The consignment number is not recorded in Comarch ERP XL system. For the purposes of Additional record, the system user must define a text attribute called VIU_DO_Shipment (VIU_DO_Przesylka), pin it to the sales invoice header and remember to fill it in from the invoice level.
“Additional record” tab, “Commodities/Services” window
The Commodities/Services window presents the elements of the invoices displayed in the Invoices window.
If there is a link between items and VAT table items, the system restricts the display of items to those that are linked to the VAT table items qualified for that VIU-DO declaration.
If for some reason the link between elements and items in the VAT table is lost, the unlinked elements will not be displayed on the VIU-DO declaration.
“Payments” tab
On the VIU-DO form, the payment is generated in Euro on the basis of the amount shown in field 18 named Total amount of VAT due to be paid (in Euro). This field is made available on tab C.6, C.7, once the declaration has been accepted or approved.
Based on the payment, the system allows the automatic generation of a transfer.
Once the declaration is submitted, the taxpayer is given a unitary unique reference number (UNR).
Please indicate only the UNR number in the payment title.
An example UNR for the EU OSS procedure is: PL/PLXXXXXXX/Q3.2022
On the [Payments] tab, in addition to the standard information, a field has been added allowing the user to enter the currency exchange rate at which the payment will be converted into PLN.
“Accounting” tab
Like the JPK-V7 files, the VIU-DO declaration can be booked, but cannot be analytically described.
Accordingly, one [Accounting] tab has been made available instead of two: Assignment, Analytical description.
From the [Accounting] tab, a standard list and actions are made available to enter a pre-assignment, delete it, modify it, post it in accordance with the adopted standard. In addition to pre-assignment, booking is also supported by the parameter Do not book. Accounting was made available not only from the VIU-DO declaration form, but also from the list of declarations. In the context menu, a Delete assignment option has been added and supported, allowing, according to the accepted standard, the deletion of an assignment without having to go to the list of accounting records to search for the assignment to be deleted.
VIU-DO declaration accounting scheme
The VIU-DO declaration accounting scheme is defined from the Document accounting schemes window, [Declarations] tab. The scope of the fields provided in the accounting scheme header has not changed.
From the [Items] tab, selecting the New button allows you to add a new item to the accounting schema.
There are three options to choose from in the “Calculate for:” field:
-
-
- Payments – possibility to delete booking of a payment created on the VIU-DO declaration, based on field no. 18. “Total amount of VAT due to be paid (in Euro)”.
The payment is expressed in Euro, it should be booked to the PLN account linked to the foreign currency account. - Amounts from declarations – the ability to delete booking of amounts linked to specific declaration fields.
- Analytical description – the VIU-DO declaration cannot be described analytically, so selecting this option will not return any values
- Payments – possibility to delete booking of a payment created on the VIU-DO declaration, based on field no. 18. “Total amount of VAT due to be paid (in Euro)”.
-
If we want to book the value associated with a specific declaration field we select “Calculate for: Amounts from declaration”. Using the Amount button, select the “Other/VIU-DO” option from the menu.
After accepting the VIU-DO option, in the next Enter declaration field number window, select the field number from which the amount to be booked is to be taken. The following six amounts are available to choose from:
The amounts in the aforementioned fields are expressed in Euro. They are converted into PLN at the exchange rate indicated on the [Payments] tab.
VIU-DO declaration submission
-
-
- The range of options on the form for the submission of VIU-DO files differs from the range of options presented on the forms related to the submission of JPK files, as the legislator has made it possible to submit VIU-DO declarations not only with a “Submission” status but also “Draft” status.
- On the VIU-DO declaration form, a commentary below boxes 7 and 8 indicates what is meant by submitting a declaration in draft form. Below is an excerpt from the form with commentary:
-
-
-
- In relation to enabling the submission of the so-called working file, a section called “Preparation of VIU-DO file” has been added next to the section called “Purpose of submission” with parameters: “Draft”, “Submission”.
- The default setting is the Draft version.
-
-
-
- Submission in draft form is subject to VIU-DO files of any status except those with the status Cancelled.
- Submission in draft is not limited.
- There is no change of status to Approved when an accepted declaration is submitted in draft form and a correct UPO is received.
- Submissions as Submission (final version) according to the accepted standard for JPK files apply to declarations with a status of: Accepted, Approved.
- If an accepted declaration is submitted as Submission, the status is changed to Approved upon receipt of an UPO confirming that the declaration was submitted correctly.
Export of the VIU-DO form to Excel
The export of the VIU-DO declaration is handled in the same way as the export of JPK_V7 files.
Printouts available from the VIU-DO declaration form
Two printouts have been made available from the VIU-DO declaration form:
-
-
- UPO form – the printout contains a range of data analogous to its counterparts available from other declaration types
- Auxiliary VIU-DO – the printout is equivalent to the VIU-DO declaration form, but is not a true copy of it. Below is an excerpt from the auxiliary printout.
-
“WSTO_EE transactions in the OSS procedure” printout available from the list of VAT registers
A new printout has been made available from the sales VAT registers level showing the VAT table items associated with WSTO_EE transactions settled in or out of the OSS procedure.
The printout is available from the By number tab, printout menu “WSTO_EE transactions in the OSS procedure” / “WSTO_EE transactions in the OSS procedure”, provided that the transaction list is narrowed to WSTO_EE and the value “Yes” or “No” is selected in the “WSTO_EE” section, in the “OSS procedure” field.
The printout responds to the list parameters.
In addition to the standard data, information on the consumption country, issue country, correction has been made available on the printout. In the summary, VAT rates are grouped by consumption country.
Serial operations
For the VIU-DO declaration, the mechanism for serially changing VAT parameters, which is made available from the sales VAT registers, has been extended.
-
-
- If in the configuration, from the [Sales]/[Parameters 2] tab, the parameter Use WSTO_EE is not selected, the range of parameters available in the Serial change window will not change.
-
-
-
- If the Use WSTO_E parameter made available from the [Sales]/[Parameters 2] tab is selected in the configuration, the range of parameters in the Serial change window will be extended to include parameters related to WSTO_EE transactions and the use or lack of use of the OSS procedure.
VIU-DO declaration
Do not include on the VIU-DO declaration and Quarter correction with the value No will be checked and deactivated
The VAT-7 Declaration section will be active
This parameter setting is due to the fact that WSTO_EE transactions not covered by the OSS procedure are not included in the VIU-DO declaration, but are instead included in the VAT-7 declaration.
-
-
- If the OSS procedure parameter is selected and a value Yes is entered in the field next to it, the parameters in the section related to the OSS procedure are automatically activated and the parameters in the VAT-7 Declaration section are deactivated.
This parameter setting is due to the fact that WSTO_EE transactions covered by the OSS procedure are included in the VIU-DO declaration, but instead are not included in the VAT-7 declaration.
Decreasing the value on a transfer package
In the case of mutual obligations, the transfer for purchase invoices is often immediately reduced by the value of the corrections. Decreasing the amount to be paid in the ERP system can be achieved by settling documents against each other and then transferring the remaining amount to the counterparty.
In the event that the user wishes to make a corrected transfer, but without prior settlement, a dedicated solution can be used on the transfer package.
Generating a correction package
In the list of unsettled payments, there are buttons to add payments to the package. Based on the payments selected, the user can:
Create transfer package – individual payments are added to the package, and if they are partly settled with another document, its number is added to the transfer title
Create transfer package with corrections – in addition to the above action, the system actively searches for corrections that have been issued to an order but have not yet been settled with it. If they are found, their value is also added to the package.
When Create transfer package with corrections is selected, a package is created with default titles that can be grouped together. The list also includes receivables resulting from corrections. Their amount is shown in red.
Once a group has been created, the value of the transfer to be made is reduced by the receivables.
Generating a package from an estimate budget
For the estimate budget, we have the same options as in the list of unsettled payments. From this level, receivables from other documents, e.g. sales invoices, can be added to the package.
It is therefore possible to deduct payables from sales invoices without first offsetting them.
Settlement of a split package
Simply reducing the value of a package does not settle the commercial documents. This occurs when the bank statement appears, which will show the value of the exported package. A new mechanism for splitting the cash-bank record is responsible for this.
Splitting the cash-bank record
Splitting the bank record allows a single transaction on the statement to be broken down into several components. This mainly applies when a company receives a transfer in which an existing receivable has been reduced by a payable. In this situation, a trade document settlement is generally created, where the remaining amount is paired with the record. However, the company may prefer to settle all invoices with a statement, which is more in line with the economic event.
Comarch ERP XL system allows separating parts of the record. This allows any commercial documents to be paired with a statement, while maintaining the account balance.
Record separation
The imported bank statement can be split on the cash-bank record settlement window. This is done using the Separate amount to new record button.
A new window opens, allowing the user to specify the amount and parameters of the new entry. The user can separate the amount with the same party or the opposite party. In such a situation, there is a decrease or an increase in the value of the split record.
After correction, a new record is created next to the current one. On the [Statement] tab of each, there is information on the original transaction amount.
Negative values represent expenditures and positive values represent increases in funds in the account.
Note: The functionality only applies to transactions in PLN currency. The breakdown of currency records will be added in future versions of the system. |
Automatic record splitting
If the user has grouped receivables and payables on the transfer package, the amount to be paid to the counterparty will be reduced. However, this will not yet result in a settlement. When the bank statement is received, the system will automatically match the outgoings to the existing package and split the record.
All receivables from the package are separated into a separate record and settled against the sales invoices. This amount increases the expenditure record and settles against the purchase invoices. As a consequence, all commercial documents are settled only with cash/bank records.
Hint: In the event that the value of the documents to be settled does not match the amount of the bank record, settlement will take place according to the original rules, i.e. only documents with the opposite party will be settled.
Such a situation may arise if the commercial documents underlying the value of the order were settled after the transfer was sent and before the statement was received. |
|
Integration with Comarch Apfino factoring
Comarch Apfino’s offer has been enriched with the possibility of ordering factoring on the basis of a list of sent invoices. Such invoices can be sent from the Debt collector’s window.
In the debt collector’s window, there is a new Factoring – Finance invoice button, which is available for outstanding invoices that are not yet overdue.
Once it is launched, a synchronisation check with the Apfino platform takes place. As with other services, it is necessary to set up an account on the platform and obtain an exchange key to allow data synchronisation.
For the invoices sent, the available financing amount is verified, as is the counterparty’s application for the factoring service. If the recipient has not been reported from within Apfino, the request will terminate with an error.
In this case, access the platform and there select Add counterparty, where the information about the entity and the financing limit assigned thereto must be completed. The basic data should already be prompted based on the order uploaded from the ERP system.
For a counterparty for which all formalities have already been completed, the invoice transfer window will appear.
When the Finance button is pressed, these invoices are reported to the Factor. A summary of the uploaded documents and their total value is displayed on the screen.
On the debt collector’s window, these are also displayed in the Factoring status column.
Other changes
New rates of allowances and lump sums for domestic travel
From January 1, 2023, new rates will apply for:
Allowances – increase in rate from PLN 38 to PLN 45
Lump sum to cover the costs of commuting by public transport – increase from PLN 7.60 to PLN 9
Lump sum for overnight accommodation (if the employee was not provided with free accommodation and did not submit a bill for hotel accommodation) – increase from PLN 57 to PLN 67.50
Hotel accommodation (eligible for the amount stated on a bill, but not more than twenty times the allowance rate per hotel night) – increase from PLN 760 to PLN 900.
In Comarch ERP XL, version 2023.0 has added new rates for allowance, travel lump sum and overnight allowance, which will take effect from January 1, 2023.
In Comarch ERP XL, version 2023.0, dated September 8, 2022, new rates have been added for capital and statutory interest for late payment, i.e. for:
capital: 10.25%
statutory for late payment: 12.25%
Shared
Remembering a selection in the counterparty list after filter changes
In the list of counterparties, an action analogous to that in the commodities list has been introduced, where the selection of records is remembered after changing the filters. This is also the case for those list items that will be hidden in the list as a result of filtering.
This means that the execution of operations for records selected in the counterparties list can be performed not only for those records that are visible as selected at the time the operation is performed. This also applies to serial operations for selected items that are performed on other objects. E.g. the Add list command when adding counterparties to a special offer, which brings up a list of counterparties in selection mode.
To ensure that all records in the list have been deselected, new Deselect all command can be used in the context menu of the commodity list.
Deselecting all records is also done automatically when the commodity list is closed.
Other changes
Offer 4.0 window with always up-to-date information
The Comarch ERP Offer window available on the Ribbon of each module (in the General menu and the Help menu) is from the new version opened in the internal XL viewer.
This displays always up-to-date information of the ERP products supported by Comarch ERP XL. From now on, changes to the displayed web page can be made regardless of which version of the System you have.
The appearance of the offer content is no different between the window called up automatically at the System start (the window on which the Do not inform me again parameter can be set) and the window called up from within the Ribbon (Offer 4.0 button).
If there is no Internet access when the window is displayed, an offline page with the offer is presented. That is, the content and images downloaded to the System on the date of release of the respective System version are displayed.
New design of AI/RPA function windows
The design of the windows on which all the functions that automate the System are presented has been modified. The list of functions is available on the [Artificial Intelligence] tab of all Comarch ERP XL modules as two lists: AI artificial intelligence and RPA Robotisation.
The tiles include the names of the functions and the areas to which they apply, the colour coding of the function activity in the left-hand side bar and additional graphical markings. When the cursor hovers over a tile, a brief description of the respective functionality is presented. At the bottom, click on Read more to go to the relevant document, which describes the functionality in more detail
For the list of RPA functions, the division into area tabs has been retained. Above the list, the possibility of filtering and sorting the tiles has additionally been introduced, which will significantly improve the search for the right function among such a broad list of possibilities.
Collaboration with Comarch WMS
Combining source (W)ZWM document items according to the configuration
On the definition of the ZWM document, there is a parameter Combine source document items, which, as of version 2023.0, is included on the (W)ZWM document for many different operations in the System. When this is set up, the sub-elements of the source documents are combined so that all sub-elements relating to the same commodity lot and type of source document are included on one element, as detailed below. In the case of documents on which combining does not apply (parameter not set), sub-elements taken from the source document are not combined, i.e. each sub-element on the stock document is at the same time a separate element.
The action so far has been characterised by randomness in the combination of sub-elements on the (W)ZWM document. If a delivery was recorded on a sub-element, it was generally combined with other sub-elements indicating the same lot, but there were exceptions to this rule. If the delivery was not saved, the combining was never performed. That is, there may have been both combined and uncombined elements on one document, although each indicated the same lot.
As the linking is done by commodity lot, which on (W)ZWM documents is only known in each case if WMS stock reservations are enabled, the functionality will only work under this condition. This means that on a WMS-enabled warehouse card, the parameter Reserve resources based on… must be checked, otherwise the combining will be performed as before.
In order to make it immediately apparent whether the System takes into account item combining/non-combining algorithms, a parameter with the same name as in the document definition is displayed on the (W)ZWM document.
Here we have three options for its “setting”:
-
-
- The parameter is visible and selected – indicating that the sub-elements are subject to combining,
- The parameter is visible and deselected – indicating that the sub-elements are not subject to combining,
- The parameter is not visible – it means operating as before, i.e. combining for all cases does not occur (it is random, as described above). It is for this reason that the parameter is hidden on all (W)ZWM documents issued before the conversion.
-
The following describes the detailed impact of the parameter’s effect on (W)ZWM documents when performing various operations in the System.
-
-
- When generating a document from orders or documents from the Production module, the source elements are the so-called sales reservations, which can be further subdivided by WMS stock reservations. Each source reservation creates a separate sub-element on the stock document and then it is relevant to set the Combine source document items parameter to (W)ZWM:
-
If no combining is to take place, then each sub-element is a separate document item,
If item combining is to take place, the sub-elements are grouped by lot, i.e. as many items are created as there are lots.
Example: Commodity with the “colour” attribute received in three deliveries (three separate batches):
– FZ-100/22, quantity of 50 pcs. colour: white – FZ-105/22, quantity of 50 pcs. colour: black – FZ-117/22, quantity of 50 pcs. colour: blue An (W)AWD document for the full quantity was generated and closed for each FZ. An ZS-12/22 document was created with items for the above commodity: – 10 pcs. colour: white (one reservation for 10 pcs.) – 10 pcs. colour: blue (two reservations for 5 pcs.). And another ZS-13/22 document with an item for the above commodity: 20 pcs. colour: blue (one reservation for 20 pcs.). We generate a single joint (W)ZWM document for both ZS documents. If there is to be no combining of items, a document with separate items for each reservation from the ZS will be created: – 10 pcs. colour: white with ZS-12/22 – 5 pcs. colour: blue with ZS-12/22 – 5 pcs. colour: blue with ZS-12/22 – 20 pcs. colour: blue with ZS-13/22 If item combining is to take place, a document will be created with the items: – 10 pcs. colour: white with ZS-12/22 – 30 pcs. colour: blue with ZS-12/22 and ZS-13/22. |
Hint: The above also applies to the creation of (W)ZWM documents by full/non-full auxiliary units. | |
-
-
- When generating a (W)ZWM document from a given type of commercial documents, the source elements are the sub-elements of these documents. Each sub-element of the commercial document creates a separate sub-element on the stock document and then it is relevant to set the Combine source document items parameter to (W)ZWM:
-
If no combining is to take place, then each sub-element is a separate document item,
If item combining is to take place, the sub-elements are grouped by lot, i.e. as many items are created as there are lots.
Example: Commodity with the “colour” attribute received in three deliveries (two separate batches):
– FZ-100/22, quantity of 50 pcs. colour: white – FZ-105/22, quantity of 50 pcs. colour: blue – FZ-117/22, quantity of 50 pcs. colour: blue An (W)AWD document for the full quantity was generated and closed for each FZ. An FS-102/22 document was created with items for the above commodity: – 10 pcs. colour: white (one sub-element with delivery with FZ-100/22) – 10 pcs. colour: blue (two sub-elements with deliveries of 5 pcs. each from FZ-105/22 and from FZ-117/22). And another FS-103/22 document with an item for the above commodity: – 20 pcs. colour: blue (one sub-element with delivery with FZ-117/22). We generate a single joint (W)ZWM document for both FS documents. If item combining is not to take place, a document will be created with the items: – 10 pcs. colour: white with FS-102/22 – 5 pcs. colour: blue with FS-102/22 – 5 pcs. colour: blue with FS-102/22 – 20 pcs. colour: blue with FS-103/22 If item combining is to take place, a document will be created with the items: – 10 pcs. colour: white with FS-102/22 – 30 pcs. colour: blue with FS-102/22 and FS-103/22. |
-
-
- When generating a document from packages or submissions, both orders and commercial documents can appear as source documents. We are therefore faced with a mixed option, where the source elements are reservations from orders and sub-elements of commercial documents. In this case, the combining is performed with additional consideration of the document types, i.e. items of the same batch will be created separately for orders (common for ZS and ZW) and separately for each of the commercial document types.
-
Example: Commodity with the “colour” attribute received in three deliveries (two separate batches):
– FZ-100/22, quantity of 50 pcs. colour: white – FZ-105/22, quantity of 50 pcs. colour: blue – FZ-117/22, quantity of 50 pcs. colour: blue An (W)AWD document for the full quantity was generated and closed for each FZ. An ZS-12/22 document was linked to the package with items for the above commodity: – 10 pcs. colour: white (one reservation for 10 pcs.) – 10 pcs. colour: blue (two reservations for 5 pcs.). And another FS-103/22 document with an item for the above commodity: 20 pcs. colour: blue (one sub-element with delivery with FZ-117/22). We generate a single joint (W)ZWM document for the package. If item combining is not to take place, a document will be created with the items: – 10 pcs. colour: white with ZS-12/22 – 5 pcs. colour: blue with ZS-12/22 – 5 pcs. colour: blue with ZS-12/22 – 20 pcs. colour: blue with FS-103/22 If item combining is to take place, a document will be created with the items: – 10 pcs. colour: white with ZS-12/22 – 10 pcs. colour: blue with ZS-12/22 – 20 pcs. colour: blue with FS-103/22. |
-
-
- When attaching different items from source documents (orders or commercial documents) to a (W)ZWM document, it is important to set the Combine source document items parameter on the (W)ZWM:
-
If no merging is to take place, then each sub-element from the source will be a separate document item,
If item combining is to take place, each appended sub-element from the source will be appended to an item with a compatible lot and compatible source document type.
-
-
- When moving sub-elements from source documents (orders, documents from the Production module or commercial documents) from the “To issue” list to the top, it is important to set the Combine source document items parameter on the (W)ZWM:
-
If no merging is to take place, then each transferred sub-element from the source will be a separate document item,
If item combining is to take place, each transferred sub-element from the source will be appended to an item with a compatible lot and compatible source document type.
-
-
- Combining never occurs for items added by hand, i.e. those without a source document. Each item added then constitutes a separate record on the (W)ZWM, even if it relates to a batch that already appears on the document.
-
Other changes
Separate “access permission” for the Dispatcher’s desktop window
In addition to the current parameter from the configuration of the Sales module (Configuration/Sales/Parameters 1) AWD/ZWM support, a new parameter Active Dispatcher desktop has been added. It determines whether the Dispatcher’s desktop button is active in the Sales module on the Ribbon. Until now, this was the responsibility of the AWD/ZWM Support parameter, which also has a different meaning in the System and the two functionalities do not always link together. Such a case can arise when no AWD/ZWM documents are planned for the regular warehouses and, at the same time, WMS-enabled warehouses are added. The parameter setting should then be as follows:
-
-
- the AWD/ZWM Support parameter unchecked, which will result in AWD and ZWM documents not being automatically generated when commercial documents are approved, but PM and WM will be generated;
- the Active Dispatcher desktop parameter checked in order to be able to add and handle (W)AWD and (W)ZWM documents.
-
The availability of the new parameter is consistent with the existing one, i.e. it is always active. On new bases, the parameter is not checked, while on existing bases it is set according to the AWD/ZWM Support parameter.
Sorting of source non-resource reservations when generating (W)ZWM with a breakdown by the aux. unit
In the functionality for the creation of (W)ZWM documents with a breakdown by the auxiliary unit from the source order, when retrieving source reservations, the principle of sorting these reservations if they have no resources has been introduced. Sorting is done by quantity in a descending manner, i.e. bookings for the largest quantities are taken into account first. With this approach, there is a chance that resources for full auxiliary units will be found for a significant proportion of the quantity.
Example: Commodity received in three deliveries:
– FZ-100/22, quantity of 50 pcs. – FZ-105/22, quantity of 50 pcs. – FZ-117/22, quantity of 50 pcs. An (W)AWD document for the full quantity was generated and closed for each FZ. A ZS document was created with an item for the above commodity in the amount of 130 pcs. Two unspecified reservations have been created for the following quantities: 30 pcs. and 100 pcs. In addition, an auxiliary unit is set on the order item: pallet with the conversion rate 1 pallet = 50 pcs. The unit has a breakdown set up on (W)ZWM documents. A parameter has been checked on the WMS warehouse to which the ZS is issued: Reserve resources based on – commercial status. A (W)ZWM document is generated for the ZS. Prior to generating, a sorting of reservations with no resources from the ZS is performed and their order is set at: 100 pcs. and 30 pcs. Two documents have been issued: 1. (W)ZWM-1 for full auxiliary units with execution of ZS reservations for 100 pcs. where resources have been included (FIFO collection of resources): – FZ-100/22, quantity of 50 pcs. = 1 pallet, – FZ-105/22, quantity of 50 pcs. = 1 pallet. 2. (W)ZWM-1 for non-full auxiliary units with an entry for 30 pcs., where the resource has been included (FIFO collection of resources): FZ-117/22, quantity of 30 pcs. = 0.6 pallet. If the order in which reservations were taken from the ZS followed the order on the ZS item (30 pcs. and 100 pcs.), then the breakdown on the (W)ZWM documents would look different. The first reservation for 30 pcs. would be treated as for a non-full auxiliary unit and would break up the first delivery with FZ-100/22, with the result that ultimately the documents would contain: 1. (W)ZWM-1 for full auxiliary units with a partial reservation for 100 pcs. where resources have been included (FIFO collection of resources): FZ-105/22, quantity of 50 pcs. = 1 pallet. 2. (W)ZWM-1 for non-full auxiliary units with entries for the remaining quantities from the reservations, where the resources have been included (FIFO collection of resources): – FZ-100/22, quantity of 30 pcs. (0.6 pallet) from the first reservation, – FZ-100/22, quantity of 20 pcs. (0.4 pallet) from the second reservation, – FZ-117/22, quantity of 30 pcs. (0.6 pallet) from the second reservation. |
Changes in the display of stock for WMS warehouses
-
-
- In the commodity list, if a warehouse with the WMS support set is selected in the filter area and the Zero stock parameter IS NOT selected, only those records are presented which have stock in the WMS, i.e. all those for which the quantity in the WMS column is greater than zero. Until now, filtering was based on the quantity in the Warehouse column, which is always zero for commodities in WMS warehouses.
- In the Stocks in warehouses form, [By attributes] tab, the Warehouse column does not currently show the stock quantity for a WMS-enabled warehouse. So far, the figure of 0.00 presented suggested that there was a lack of stock for commodities, which is not true as the stock quantity for such commodities is presented in the WMS column.
-
Collaboration with Comarch POS
Synchronisation of related commodities and substitutes
Related commodities and substitutes are objects registered on the commodity cards, on the [Substitutes] tab. It is a type of link between commodities that allows better management of sales, proposing additional commodities or substitutes. The types of commodity relationships can be defined in the category dictionaries in the Administrator module. All types of links (including substitutes) are submitted to Comarch POS.
Conditions for the transfer of related commodities and substitutes
Those links are sent to Comarch POS that have a centre added on the [Places in the company structure] tab that is linked to a Comarch POS branch or a centre superior to the above.
-
-
- Related commodities
- The linking of commodities with other commodities is transmitted provided that the commodities belong to the tree of commodity groups transmitted to the POS.
- A link will not be visible in the POS if the type of link is marked as inactive in the category dictionaries.
- Substitutes
- Substitutes of the commodity that meet the following conditions are sent to the POS:
- one-sided or double-sided substitute (substitutes that are not sent: equivalent to all)
- the commodity to substitute ratio is 1:1
- document type is selected: Expenditures
When a substitute/related commodity is deleted or modified in Comarch ERP XL, the changes are sent to the POS and updated.
Visibility of related commodities and substitutes in POS
-
-
- Commodity card (article) preview in Comarch POS
- Menu Articles > Preview > [Related articles] tab
-
Any product can be selected from the list of visible commodities and added to the sales document.
Credit limit support
The possibility of supporting credit limits in cooperation with Comarch POS was introduced. Limits are submitted to the individual POS and controlled during the sale. Counterparties can have an unlimited limit, limited to a certain amount, or can use another counterparty’s limits. The option to use the acquirer’s limit control has also been supported.
Configuration of limit operation in cooperation with POS
On the Comarch POS branch configuration window, the following parameters have been added to the [Counterparties] tab:
-
-
- Credit limit support – when selected, limits will be submitted to the POS and controlled during the sale
- Maximum time since last synchronisation (m) – possibility to set the maximum time in minutes during which it will be possible to use locally stored limits when the POS connection to the head office is not active.
- Presentation of available limit – this parameter has three options for deciding how limits are to be presented during sales:
- Subtract document value – the value of items added will automatically reduce the value of the available limit
- Do not subtract the document value – the available limit will not decrease as more items are added to the document.
- Do not present – the limit amount will not be presented, however, when approving the document, the system will check the limit and warn or block according to the document definition settings.
-
Transmission of limit-related settings
Cashless payments required
In order for the limit-related functionalities to work, it is necessary to send at least one payment to the POS station that is not a cash payment, i.e. it does not create cash-bank records when the document is approved. Overdraft protection is applied only for such payments.
At the POS, at least one payment must be added that has the option selected in the No KP/KW column as shown below.
Whether to include documents that do not generate payments in the limit
This setting is sent on the basis of the FS document definition in the main centre. In Comarch POS, this setting is common to all documents and to the display on the counterparty card. In Comarch ERP XL, it is defined for each document separately. As limits are most often applied on invoices, it was assumed that this setting would be taken from the sales invoice definition.
How to react if the limit is exceeded
This setting is transmitted on the basis of the definition of the individual documents (FS, PA) in the centre associated with the Comarch POS branch. Depending on the setting of the parameters as follows, a warning may appear or the approval of the document may be blocked when approving a document with a cashless payment method. It is also possible to skip the limit information if the Allow option is selected.
Transmission of limits
All current credit limits set for each counterparty are transmitted. Limits that expired are not transmitted. Any change to the limit amount is updated and deletion of the limit results in its removal at the POS.
-
-
- If the Unlimited parameter is selected on the counterparty’s card, [Credit limits] tab, limits will not be transmitted to the POS and the limit will not be controlled.
- If the aforementioned parameter is not selected but the limits are not set, then the POS will display information about no credit limit being granted.
- If you add a credit limit on the [Credit limits] tab, the limits will be displayed and controlled accordingly.
- If a different payer is indicated on the counterparty’s card, [Commercial] tab, and the following parameter is selected: Payment form and due date and credit limit from the payer’s card, then the credit limit will be checked for the payer set for the counterparty.
-
Note: The payer’s limit will only be supported if the counterparty is the payer. Where the payer is a bank, office, employee or head office, the payer’s limit will not be taken into account. In such a situation, the limit will be taken from the counterparty. |
On-line control of limits
It is very important that during the sale it is possible to determine the most current use of the credit limit, as the limit can be used in another position or in the Comarch ERP XL system. When the counterparty data is displayed in POS, the limit will be retrieved from the XL and the current total and available limit will be displayed. Similarly, when issuing sales documents, the available and total limit of the counterparty or its payer will be presented, and when approving an FS or PA document with cashless payment, there will be a check or warning if the limit is exceeded or missing.
If for any reason an online connection is not possible, then the limit can be used for a specific period of time, the length of which is set in the branch configuration.
Acquirer’s limits
If the following parameter is selected in Configuration on the [Sales]/[Parameters2] tab: Check the acquirer’s limit, in which case the limits set on the card of the counterparty marked as an acquirer, on the [Acquirer’s limits] tab, will be transmitted to the POS. The acquirer’s limit is set separately for each centre, so in order for the limit to go to a Comarch POS branch it must be assigned to the relevant centre associated with the branch.
In order for an acquirer’s limit to take effect for counterparty, it is necessary to assign an acquirer on the counterparty’s card, on the [Other] tab. The acquirer must be selected from the list of counterparties (cannot be an employee).
An acquirer’s limit is treated like another payer’s limit, i.e. if an acquirer is assigned to counterparty and a limit is set on the acquirer’s card, the assigned acquirer’s limit will be checked on the counterparty’s card and during sales to that counterparty.
If acquirer’s limits are used (Check acquirer’s limit parameter enabled), other counterparty limits are not supported
The rules for the transmission, control and online control of acquirer’s limits are the same as those of the counterparty/payer.
Parameters for opening cash register reports
New parameters have been introduced to allow more flexible control over the opening and closing of cash register reports. Until now, the cash register report was opened based on the date and time the session opened at the POS and closed based on the date and time it closed. In cases where it was not possible to import all cash-paid documents or manual deposits and withdrawals, the report was not closed until all records had been imported.
In the POS configuration window, new parameters have been added to the [Parameters] tab:
-
-
- Opening and closing cash register reports based on the opening and closing of the POS sessions
- By default, this parameter is selected to maintain the previous functionality.
- If the user does not want reports to be created on a per-session basis, they should deselect the above parameter. When unchecked, the cash register entries will go into the currently open report. If there is no open report to which a record can be added, a new report will be opened with the date and time the first document or record was uploaded to the register in question. The closing of the report should be performed manually on the Comarch ERP XL side. Once the report is closed, if further documents or records are uploaded, the system will open another report.
- Daily opening of cash register reports during import of the first document
Collaboration with Comarch Shipping
Contact person and contact details provided on request
We have added the possibility of setting up a contact person and optionally their contact details to the parcel document, which is described in more detail in section Address details and contact person on the Parcel document.
This data is passed on to the Shipping orders when they are created from the System (Shipping order (Zlecenie Nadania Przesyłki, ZNP) command from a number of different document lists) as follows:
-
-
- The contact person from the parcel is set as the Recipient’s Contact person. If the person has not been set up on the parcel, then there is no change to the previous action and the Contact person on the order will not be filled in.
- The contact details provided on the order are taken as they appear on the parcel. That is, depending on the configuration, there may be data from the address or data from the contact person.
-
As only single-parcel shipments are currently handled, the contact person and contact details are always taken on the order from that particular parcel.
Collaboration with wszystko.pl
Changes at the wszystko.pl branch
With the development of the integration with wszystko.pl in the Branch administrator module, the form of a wszystko.pl-type branch has been expanded. Some of this information is also included in the creation stages of such a branch, as discussed more in the following subsections.
Downloading dictionary data
When creating a branch, in the last step, the names of the dictionary data are taken from wszystko.pl, which can be used on categories and commodities. These include:
-
-
- Names of predefined dictionaries: Execution time, Measurement unit;
- Names of user’s dictionaries: Delivery price list, Guarantee conditions, Complaint conditions, Return conditions.
-
Information that the names of the dictionary data will be retrieved is provided on the form for this step, and the execution of the operation is accompanied by an operation log.
Hint: In order for the names for all dictionaries to be imported, it is necessary to correctly establish a connection to wszystko.pl. If this has not been done before, a message about lack of authentication will appear and the names for the user dictionaries will not be retrieved. | |
In databases where branches were defined in an earlier version of the System, the operation available under the Download dictionary data button located on the right-hand bar of the branch form can be used to download the names of the dictionary data. The button can be used during further cooperation with wszystko.pl to retrieve changed dictionary data names or when new records are added to the dictionary on the portal, e.g. defining a new delivery price list.
The retrieved dictionary names are displayed on the [Parameters] tab of the branch form, where it is possible to filter down to records linked to a specific dictionary.
The tab also contains an additional column ERP XL name, where it will be possible to indicate the corresponding dictionary record from the System, which is identical to the dictionary data from wszystko.pl. This does not apply to dictionary records for offers (it will only be relevant for the integration of orders), so all items currently downloaded have this information in this column.
Downloading the category tree
On the right-hand branch form bar, there is also the Download categories button for downloading data from wszystko.pl. Its use allows all categories available on the portal to be downloaded to assign them to commodities. The categories themselves are then downloaded, without parameters.
As the category list contains a large number of records, the retrieval is done in packages, as the log of the operation informs us. The operation can also take a while.
The downloaded records are presented on the [wszystko.pl] tab of the commodity list in the form of a tree, which is described in more detail in the following sections.
The import button can be used at any time to download new categories added to the portal. On subsequent imports, the names of categories already downloaded will not be changed. Nor will categories be removed, even if they have been deleted from the portal in the meantime.
Configuration parameters for the integration
On the branch form of type: wszystko.pl, configuration parameters have been added on the [Export] tab to differentiate data exchange activities.
In addition to the existing possibility of specifying the type of price to be exported, there are:
-
-
- Parameters that will be used in the next version of the System for the data synchronisation service, i.e. all those in the Automatic data update area and the Publish offers parameter.
- Stock export parameter, which applies to both manual commodity upload operations and the future synchronisation service. In the current version, it determines whether the commodity status from XL will be submitted when the Send to wszystko.pl operation is set up (parameter selected) or whether the statuses are not to be transmitted when the offer is set up (parameter not selected).
-
Another parameter: Include reservations, which causes all active reservations for a commodity to reduce the balance sent to wszystko.pl (if selected) is closely related to the above.
Removing the wszystko.pl connection
Once the connection to the wszystko.pl account has been correctly established, the Delete connection button has been added to the branch definition.
Once it is used, the connection is removed as well as the authorisation data enabling the integration.
-
-
- It is also possible to disable integration with the external system on the wszystko.pl side. After this operation, the integration to the Comarch ERP XL website will also stop working, as the access data stored in the database will no longer be valid on the portal. However, this data will not be automatically deleted from the database, but only when editing the wszystko.pl branch form in the Branch administrator, the following information will appear: NOT CONNECTED.
-
In either case, it will no longer be possible to exchange data between the System and the portal until the connection is re-established. When attempting to perform a data exchange operation with the portal, Users will be notified as follows:
-
-
- If the connection was deleted from within the System, a message will appear: The connection to your wszystko.pl account has not been set up or established. It is not possible to exchange data with wszystko.pl.
- If the connection was deleted from the portal, the logs of the data exchange operations performed will show that the authorisation was incorrect.
-
[wszystko.pl] tab in the commodity list
On the [wszystko.pl] tab of the commodity list, a panel has been added to show the categories downloaded from wszystko.pl. The ability to filter commodities by offer status and to perform operations entered for integration has also been added.
Category tree from wszystko.pl
The list in the left-hand panel displays a tree of categories downloaded from wszystko.pl. It is not possible to add or delete records for this area.
However, you can search for tree items by typing a string in the filter field above the list and selecting the Find next button or using the <F7> button. In line with the button’s name, each time it is pressed, it will “jump” to the next item in the tree that contains the search term.
It is possible to edit the category form for each tree record on the last level. This only applies to the last level, as these are the categories that are selectable on the commodity, so additional settings have only been made for them.
On the category form, it is possible to enter dictionary data, i.e. select one record from the dictionaries imported from the wszystko.pl branch level. This applies to dictionaries: Measurement unit, Execution time, Delivery price list, Guarantee conditions, Complaint conditions, Return conditions. If these are filled in, the completed dictionary data will be set on the commodity when the category is added.
In addition, it will be possible to set dictionary values from the category on commodities linked to it on request. This is done using the Update dictionary data on commodities related to the category button. A rule has been introduced here that only those dictionary values that have been filled in on the category are stored on commodities when updating. The operation therefore does not clear the data on commodities from those dictionaries that have an “empty” value on the category.
The category form also displays a list of parameters assigned to it. The list shows in bold those parameters that are mandatory to be filled in on offers. Parameters from the categories are also transferred to the commodity cards when adding a category to the commodity.
The list of parameters for a category is only completed when it is first selected on the commodity, as it is then downloaded into the System from wszystko.pl. This support was introduced deliberately because of the large number of last-level categories, where each category has at least several parameters, so it would be a huge amount of data to download into the System. Since it is unlikely that all categories are used in a given database, it is only when a category is ‘used’ that it makes sense to download its parameters.
Operations on the commodity list
On the [wszystko.pl] tab of the commodity list, commands have been added to the context menu for both operations on the commodity cards themselves and operational activities related to data exchange with wszystko.pl.
Operations in the second group of commands allow the category for the selected commodities to be changed:
-
-
- Set category for commodities – allows the selected category to be set on the selected commodities. If a category has already been filled in on the indicated commodity, it will be replaced by the newly selected category. At the same time as changing the category, all parameters are changed along with the values filled in for them. Dictionary values are also updated as described above.
- Remove categories from commodities – allows deleting the category set on selected commodities. The deletion of a category here also deletes all parameters with the values filled in for them.
-
If the commodity has already been transmitted to wszystko.pl and an offer has been made, it is not possible to change the category. In such a case, both the replacement of the old category with a new one and the clearing of the category is blocked, which is communicated to the user with an appropriate message in the log.
Other operations are related to the transfer of data between the System and the portal, namely:
-
-
- Send to wszystko.pl – allows to set up an offer on wszystko.pl (also with publication),
- Update in wszystko.pl – allows to update an offer on wszystko.pl (also with publication),
- Download offer status from wszystko.pl – allows setting the current offer status from wszystko.pl on a commodity.
-
A detailed description of how these operations work is described later in this chapter.
In addition, a new Offer status filter field has been added below the list (as shown in the category tree on the [wszystko.pl] tab) to limit the commodity list to: all not shipped, all shipped or to offers with a specific status from wszystko.pl that is currently stored on the commodity cards in the System.
Data for wszystko.pl integration on the commodity card
When starting to work on the integration of the wszystko.pl portal for commodities to be displayed on the portal as offers, the data required for these offers must first be completed. This data is included on the [Applications]/[wszystko.pl] tab:
dictionary data,
category and parameter values (especially mandatory parameters).
In addition, other data to be transmitted should be borne in mind, i.e.: commodity name and description, VAT rate, price, attachment.
Once all the data on the commodity card has been filled in, it can be uploaded to the portal to create an offer and publish it. From the commodity card level, operations are also available for the offer itself: viewing, editing and deleting.
The remainder of the chapter provides a more detailed description for the above information.
Setting of dictionary data, categories and parameter values
When the relevant category from wszystko.pl is selected on the commodity card, the dictionary data values and parameters assigned to it are retrieved and set. Parameters are displayed in alphabetical order for the name, and mandatory ones have the name additionally marked in bold.
Both groups of values can be completed and changed on the commodity card.
Dictionary data can be set by selecting another record from the dictionary list. Deletion of values is possible by selecting an empty record.
Parameter values are edited in Edit-In-Place mode in the Parameter value column. The appearance of the field to be filled in depends on the type of parameter concerned:
-
-
- Text – a simple text field is edited, for which 255 characters are always possible. We do not limit the number of characters, even if such a limit is introduced on the portal.
- Number – possibility to fill in a numerical value according to the restrictions on the portal (number of decimal characters, value from the range specified on the portal). If the numerical value of a parameter has a unit assigned to it, we display this in the parameter name in brackets.
- Single record selection list – a simple drop-down list with the possibility of selecting a single record.
- Unlimited record selection list – when you double-click on a field with a value, the tag shown before appears and a new window with a list of available values appears, where it is possible to select all records.
-
Once the relevant records have been selected, they are displayed in the parameter list, separated by an “I” separator, as shown below:
-
-
- Limited record selection list – similar operation to that described above, except that if more than the allowed number of records is selected, a message will appear indicating that the allowed number has been exceeded and the window with values cannot be saved.
Hint: In the current version of wszystko.pl, the only parameter with a limited number of records to select is: Colour. | |
-
-
- Numerical range – after double-clicking on the value field, a marker appears as for a multi-value list and a new window to complete the limit values:
-
Once the relevant values in the range have been entered, they are displayed in the parameter list separated by a semicolon, as shown below:
Below the list of parameters, there is a bin button that allows you to delete the value for a single parameter. This allows values to be quickly deleted, especially in the case of multiple-choice lists or a completed value range, where it is not possible to explicitly clear the field value.
Note: No control of the completion of all mandatory parameters has been introduced. It is possible to save the card even if their values are empty. |
Once all the data on the commodity card has been filled in, it can be submitted to the portal to create an offer ( Send offer to wszystko.pl button), which is described in detail in the next section: Changes to the mechanism for creating offers from commodities.
Please note that once the commodity has been uploaded to the portal and an offer has been created, it is no longer possible to change the category for the commodity, but all other dictionary data and parameter values are active. Once these have been changed, it will be possible to carry out an operation to update the offer on the portal, which is also mentioned in the following sections. This will allow, for example, missing parameter values to be filled in for offers that have already been uploaded to the portal, provided that the offer status allows this.
Viewing and editing an offer
If, after uploading the commodity data, an offer is successfully created on the portal, the following data is saved in the commodity, as before: Offer ID at wszystko.pl, offer status and link to the offer. Two operations are currently available for the saved link:
-
-
- Offer view (default operation for the button), which calls up the offer in viewer mode in an external viewer.
- Edit offer allowing the offer to be edited in an external viewer. Editing of an offer is only possible until it is published, after which it always acts as a preview.
-
Changes to the mechanism for creating offers from commodities
The offer creation is available in the commodity list as a serial operation Send to wszystko.pl for selected records (on all tabs, except for the [Search] tab) and on the commodity card itself, under the Send offer to wszystko.pl button on the [Applications]/[wszystko.pl] tab.
Transmitted data
The previous Send to wszystko.pl operation from the commodity list or from the commodity card has been enhanced with new data sent to the offer. Some changes have also been made to the data transmitted to date, as described below.
A summary of the set of data to be transmitted when creating offers from commodities is shown in the table below. Bold indicates this data that has been added in the new version.
Transmitted data | When is sent? |
Goods name | Always |
VAT rate | Always |
Price | Conditionally, if a price type has been set in a branch |
Description | Always |
Index data | Always |
Category | Always |
Category parameter values (including EAN) | Always |
Available stock levels | Conditionally, if the parameter Export stock is set in the wszystko.pl branch and the parameter Do not control stock is not selected on the commodity |
Attachment | Conditional if there is an attachment added for which the parameter is set: Availability in applications – wszystko.pl |
-
-
- Transmission of name and description
- Until now, the name was taken from the [General] tab of the commodity card and the description was not transmitted at all. Now, the name and description are first taken from the Polish translation form (as shown in the green box below). If not filled in there, this data is taken directly from the commodity card (figure below, dark blue boxes).
-
-
-
- If the name or description exceeds the number of characters allowed on the portal, then the offer will not be saved and an error message from wszystko.pl will be displayed in the log.
- Price – a price is always sent according to the type set on the wszystko.pl branch. This is the actual gross price for the commodity, so if the price is not set, a value of 0.00 is sent.
- As prices on the portal are only allowed in PLN, if the price for the commodity in the System has a different currency, we do not send any value. Also, if the price type is set to <none> on the wszystko.pl branch, then no price is sent.
- Dictionary data – all the completed dictionary data from the commodity card are transmitted, so that the following information is completed in the offer: Execution time, Measurement unit, Delivery price list, Guarantee conditions, Complaint conditions, Return conditions.
- Category and parameters – the category is uploaded together with the values filled in for the parameters. Since the vast majority of restrictions on parameter values are guarded when they are entered on the commodity, there should be no problem in saving them in the offer. However, should any of the values not meet the requirements, then the offer will not be saved and the log will display an error message from wszystko.pl indicating an incorrect value for a particular field.
Hint: The “EAN” is also taken into the parameter list, so if you want its value to be sent to the quotation, it must be completed.
This is a change from the previous operation, where the value from the “EAN” field on the commodity card was transmitted. The change is due to the fact that not every category supports this field, so we cannot always submit it to avoid unnecessary errors from the API. |
|
Sending an attachment with the commodity
-
-
- When the commodity is transmitted for the purpose of creating an offer, a single attachment from the commodity card that meets the following requirements in XL is also sent:
- The contents of the attachment must be stored in the XL database,
- The first attachment from the list for which the parameter Availability in applications – wszystko.pl is set is taken into account for submission.
-
Verification of the other conditions for the “attachment correctness” is performed by the wszystko.pl tools at the import stage. In this respect, the following principles should be borne in mind.
-
-
- Required file parameters that are verified by the portal when importing files into wszystko.pl:
-
The maximum size per photo is 5 MB.
The side length of the photo must not be less than 480px. If it is larger than the allowed 2560px, the file will be converted to the required size on import.
Acceptable forms: .jpg, .png and .webp.
The main photo must comply with the Terms and Conditions of wszystko.pl.
These parameters may change as the application develops.
If any of the requirements are not met, the offer will be added, but without the file. A message will appear stating that the attachment has been incorrectly verified.
-
-
- Do not use compressed files – they will not be added with the offer, you will get a message that the attachment has not been correctly verified. Therefore, data compression should be disabled in the attachment type settings (set to: No).
- Do not send PDF attachments (do not set the Availability in applications – wszystko.pl parameter for them). As these files are available elsewhere on the portal, their import will be performed, but as they are not supported for offers, the offer will ultimately not be added due to an error.
-
Transmission of available stock for commodity
Submitting available commodity stocks has been supported, as long as the Export stocks parameter is set on the wszystko.pl branch and the Do not control stock parameter is not selected on the commodity ([Applications]/[Common] tab). The commodity stock calculated for the warehouses assigned to the wszystko.pl branch, after taking into account any quantities from active reservations, is then transmitted.
If the calculated commodity stock is a non-integer number, then the quantity after the decimal point is not transmitted, as only integers are allowed on the portal. In order not to submit excessive commodities, quantities are rounded down.
The unit for the quantity available in stock is the one set in the new dictionary data for wszystko.pl on the commodity card (Unit field as described in Setting of dictionary data, categories and parameter values).
Hint: If no value is set on the commodity for Unit, then “pieces” is submitted by default as the most frequent value. This makes it unnecessary to fill in this field on all commodities. Just fill it in where a different unit is applicable. | |
Updating data on offers
The offers updating is available in the commodity list, on the [wszystko.pl] tab as a serial operation Update in wszystko.pl for the selected records.
It is possible to update all data on offers linked to the indicated commodities, i.e. everything that is transmitted when the offer is created or the prices themselves or the commodity stocks themselves (quantity of commodities in stock).
Note: The update is only performed for commodities that have a link to an offer in wszystko.pl. Other commodities are omitted, so there will be no information for them in the log. |
An update with the all option will only execute for offers in Draft or Incorrect status. For other statuses, it is not possible to fully change the data on the portal, so for them, changing everything is blocked at the execution stage.
Hint: It is not advisable to modify categories on offers added on the portal as drafts if they come from Comarch ERP XL and the category is also set on the commodity. For such cases, an update operation from the System side will not always be successful. | |
For offers in the Published or Completed status, it is only possible to change the prices or commodity states themselves, so the other two options are dedicated to them: only prices and only commodity stocks. If an offer in a different state is indicated for any of these options to be changed, then the change will not be executed.
When updating prices and stocks, similar rules were applied to the creation of the offer:
-
-
- The price is only transmitted if a specific price type has been set on the wszystko.pl branch and the specified price on the commodity has the currency PLN.
- Stocks for commodities are transmitted if the Export stocks parameter is set on the wszystko.pl branch and the Do not control stock parameter is not selected on the commodity ([Applications]/[Common] tab).
- If an offer with the specified Id does not exist on the portal, the commodity card will have the relationship removed, that is: Number, status and Link, and the user will be notified by an appropriate message in the operation log.
-
Other operations
Downloading offer status from wszystko.pl
With each operation of data exchange with wszystko.pl (submission/update), the current status of the offer on the portal is always retrieved, which is saved and displayed on the commodity card next to its number.
Downloading the status can also be done at any time using the command from the commodity list context menu Download offer status from wszystko.pl. The current status will then be recorded on the commodity card. Here, you may also be informed that an offer with the specified Id does not exist on the portal if it has been removed from the portal.
Publishing offers
Publishing offers from the System is available during the following operations:
-
-
- When creating an offer (Send to wszystko.pl command),
- When updating the offer data (Update in wszystko.pl command, if an update of all data has been selected),
- As a separate publication operation without data update (Update in wszystko.pl command without selected data update).
-
When publishing an offer on the portal, it is always verified that all mandatory fields are filled in (category and mandatory parameters, VAT rate, price, quantity, description, attachment). If a value is missing for any field, the System will communicate this in the log and the offer will not be published. What is more, in the case of a publication while an offer is being created, the offer itself will not be added to the portal either, and information about the missing fields will be displayed in the log.
Hint: When publishing an offer without updates, the commodity name must always be submitted to the portal, so if it has been changed in XL, this will be sent to the offer before it is published. | |
Deleting an offer
Deleting an offer from within Comarch ERP XL is only available from the commodity card level, i.e. as an operation for a single record. If the commodity card contains information about a related offer, the Delete offer from wszystko.pl button is displayed next to the number and status of the offer.
Before carrying out the operation, the user is informed that it will result in the deletion in wszystko.pl of the related offer, but the dictionary settings, categories and parameter values will remain unchanged on the commodity. If this is confirmed, the offer will be deleted on the wszystko.pl website and, at the same time, the fields with the offer ID, link and status will be cleared on the commodity card.
Deleting an offer is only possible for those in Draft status, so the operation will not take place for the others. In addition, if the offer is not found on the portal, the above data will be deleted from the commodity card. The user will be notified of any special cases that arise with an appropriate message.
Error logging
In the logs of the data transmission operation from the System, messages from wszystko.pl are presented indicating the reason for errors in the verified data, e.g. forbidden characters in the name of the offer or attachment size being too large.
As the portal develops, the number of messages will be expanded, so for some of the data in the logs, there may still be generic messages about faulty verification resulting in the data not being saved on the portal.
New Action parameters for wszystko.pl have been added to the list of operator bans, which blocks the following operations for operators:
-
-
- Transmission of data from the commodity to create an offer (both from the commodity card and from the list),
- Serial update of data on offers in wszystko.pl.
- Deleting an offer from wszystko.pl.
-
Other data completion operations on the XL side and data integration with wszystko.pl are not blocked.
Functions not available in XL Start
In Comarch ERP XL Start version, transport documents are not available, so the changes described in chapters Address details and contact person on the Parcel document and Contact person and contact details provided on request (cooperation with Comarch Shipping) will not be available.
The Comarch ERP XL Start version also does not have Agreements available, so the changes described in chapter Ergonomics of operations on agreements will not be available.
List of figures
Fig. 1. Parameter for Operator authentication in KSeF using token 7
Fig. 2. Generating a token on a Company stamp 8
Fig. 3. User’s current KSeF session and option to close it/download an UPO 9
Fig. 4. KSeF session number within which the document was submitted 9
Fig. 5. Configuration parameters for KSeF integration 10
Fig. 6. Acceptance of operations related to the change of the KSeF environment to the production environment 11
Fig. 7. Saving directory for .xml files of the submitted invoice/downloaded UPO 12
Fig. 8. KSeF parameters on the FS definition 13
Fig. 9. KSeF parameters on the counterparty template and card 14
Fig. 10. KSeF permissions on the Operator card 15
Fig. 11. Serial change of the Submit to KSeF parameter with the context menu option 16
Fig. 12. KSeF parameters on the FS form 17
Fig. 13. KSeF integration operations on the FSE document form 18
Fig. 14. KSeF parameters on the simplified (A)FS form 19
Fig. 15. Optional invoice submission during approval 20
Fig. 16. Warning of the submission of a document with a date of issue that does not match the current date 20
Fig. 17. Document submission to KSeF performed from its form 21
Fig. 18. Serial submission of invoices to KSeF from the documents list 22
Fig. 19. Change of the KSeF status and other information concerning the document submission 23
Fig. 20. .xml file of the submitted invoice as its attachment 24
Fig. 21. Visualisation of invoices in the National e-Invoice System 25
Fig. 22. Downloading UPO from the document form – one document submitted in a given session 27
Fig. 23. Downloading UPO for a session in which multiple documents were submitted 28
Fig. 24. .xml file of downloaded UPO as invoice attachment 29
Fig. 25. Downloading UPO for multiple KSeF invoices/sessions 30
Fig. 26. Downloading UPO for documents submitted during the current KSeF session 31
Fig. 27. Positive validation of the document according to KSeF schema 32
Fig. 28. Document validation according to KSeF schema – example of irregularities in counterparty address data 33
Fig. 29. Serial validation of invoices against the KSeF schema using context menu options 33
Fig. 30. New columns and filter by KSeF Status in the FS list 34
Fig. 31. KSeF number of the original on FSK/FKE manual corrections 35
Fig. 32. Optional printing of the invoice KSeF number 36
Fig. 33. Blocking of cancellation/deletion of a document submitted to KSeF 37
Fig. 34. Counterparty’s prefix and VAT ID (NIP) and Foreign number in the document list using the FSE list as an example 39
Fig. 35. The [VAT] column in the list of sales invoices 39
Fig. 36. Sale date on the FSE list 40
Fig. 37. Date of issue and purchase on the FAI list 40
Fig. 38. Address details, contact person and contact details on the parcel 42
Fig. 39. Example of a paused execution of an operation, i.e. with a pause in progress 45
Fig. 40. Pause area in the Operation execution window when no pause is currently in progress and the Pause button is available 46
Fig. 41. Pause area in the Operation execution window when pause is currently in progress and the Resume button is available 47
Fig. 42. Completed execution of the operation, with the duration and settlement time of the pause deducted from the aggregate execution time and settlement time of the operation 49
Fig. 43. Button to add a pause (stop the operation) in the Production order window, on the Processes tab 50
Fig. 44. Button to end a pause (resume the operation) in the Production order window, on the Processes tab 51
Fig. 45. Button to add a pause (stop the operation) in the Production order window, on the Operations tab 51
Fig. 46. Button to end a pause (resume the operation) in the Production order window, on the Operations tab 52
Fig. 47. Button to add a pause (stop the operation) in the Production orders list, in the drop-down section of the Order details, on the Execution report tab 52
Fig. 48. Button to end a pause (resume the operation) in the Production orders list, in the drop-down section of the Order details, on the Execution report tab 53
Fig. 49. Button to add a pause (stop the operation) in the Production master order window, on the Execution report tab 53
Fig. 50. Button to end a pause (resume the operation) in the Production master order window, on the Execution report tab 54
Fig. 51. Button to add a pause (stop the operation) in the Operation schedule window 54
Fig. 52. Button to end a pause (resume the operation) in the Operation schedule window 55
Fig. 53. New category dictionary: Pause reasons 56
Fig. 54. New parameter for deciding whether the pause is to reduce the operation execution settlement time, in the Edit company structure window, Production 2 tab 57
Fig. 55. Execution statuses displayed in the headers of the Operation execution window 58
Fig. 56. New Status column and execution icons in the Production order window, on the Operations tab 59
Fig. 57. New Status column and execution icons in the Production orders list, in the lower Order details section on the Execution report tab 59
Fig. 58. New Status column and execution icons in the Production master order window, on the Execution report tab 60
Fig. 59. Execution statuses displayed in the Status column and corresponding icons in the Operations schedule window 60
Fig. 60. Execution statuses displayed in the Status column and corresponding icons in the Change or add resources window 61
Fig. 61. New filters for operation execution statuses in the Operations schedule window 61
Fig. 62. New options in the Status filter in the Change or add resources window 62
Fig. 63. New fields for entering quantities and indicating the product on the KLK 63
Fig. 64. List of products of a given technology in a selectable mode 64
Fig. 65. Recalculation of KLK for any quantity of product 64
Fig. 66. New columns that show the quantity of material/product expressed in the auxiliary unit 65
Fig. 67. KLK – information on the calculated cost and unit cost of the product 66
Fig. 68. New parameter, when selected, to highlight zero costs or prices on the KLK 67
Fig. 69. KLK list – new columns with product code and name 68
Fig. 70. Options for starting operations in the Operations schedule window 69
Fig. 71. Options for executing operations in the Operations schedule window 70
Fig. 72. Company stamp, Declarations tab, VIU-DO (OSS) field 71
Fig. 73. Ribbon, Declarations, Other declarations menu 71
Fig. 74. Tax returns window 72
Fig. 75. VIU-DO declaration form, General tab 73
Fig. 76. VIU-DO declaration form, Header tab 75
Fig. 77. VIU-DO declaration form, Exchange rates tab 76
Fig. 78. VIU-DO declaration, tab C.1, C.2 77
Fig. 79. VIU-DO declaration, tab C.1, C.2 78
Fig. 80. Sales invoice qualified for inclusion on the VIU-DO, in section C.2 78
Fig. 81. VIU-DO declaration, tab C.1, C.2 79
Fig. 82. Sales invoice qualified for inclusion on the VIU-DO, in section C.3 79
Fig. 83. VIU-DO declaration, tab C.3 80
Fig. 84. Sales invoice qualified for inclusion on the VIU-DO, in section C.5 80
Fig. 85. VIU-DO declaration, tab C.4, C.5 81
Fig. 86. VIU-DO form, Record tab 81
Fig. 87. VIU-DO form, Record tab, By declaration section window 82
Fig. 88. VIU-DO form, Record tab, Sales details window 82
Fig. 89. VIU-DO form, Additional record tab 83
Fig. 90. VIU-DO form, Payments tab 85
Fig. 91. VIU-DO form, Payments tab 85
Fig. 92. Accounting scheme form, General tab, added from the Document accounting schemes window, Declarations tab 86
Fig. 93. Accounting scheme form, Items tab, added from the Document accounting schemes window, Declarations tab 86
Fig. 94. Accounting schema item, added from the Document accounting schemes window, Declarations tab 87
Fig. 95. Accounting schema item, added from the Document accounting schemes window, Declarations tab 88
Fig. 96. Window: Submission of VIU-DO declaration to the Ministry of Finance’s e-Declarations (e-Deklaracje) gateway 89
Fig. 97. Auxiliary printout for the VIU-DO declaration 90
Fig. 98. Sales VAT Register window – printout menus 91
Fig. 99. Printout made available from the Sales VAT register, By number tab, from the WSTO_EE transactions in the OSS procedure menu 92
Fig. 100. Configuration, Sales/Parameters 2 tab, Use WSTO_EE parameter 93
Fig. 101. Serial operations window 93
Fig. 102. Serial change window, made available from the VAT records, “Use WSTO_EE” parameter enabled 94
Fig. 103. Serial change window, made available from the VAT records, “Use WSTO_EE” parameter enabled, OSS procedure: No 95
Fig. 104. Serial change window, made available from the VAT records, “Use WSTO_EE” parameter enabled, OSS procedure: Yes 96
Fig. 105. Package generation options 97
Fig. 106. Grouped package with corrections 97
Fig. 107. Generating a package from an estimate budget 98
Fig. 108. Option to separate part of the record 99
Fig. 109. Parameters of the separated record 100
Fig. 110. Information on the original transaction amount 101
Fig. 111. Automatic imported record splitting 101
Fig. 112. Invoice financing 102
Fig. 113. No limit assignment 103
Fig. 114. Adding a counterparty limit 103
Fig. 115. List of invoices for financing 104
Fig. 116. Financing outcome 105
Fig. 117. Viewing the factoring status 105
Fig. 118. Configuration, Delegations tab – new rates of allowances and lump sums 106
Fig. 119. Configuration, Interest tab – new rates of capital interest, statutory interest for late payment 107
Fig. 120. Command to serially add counterparties to a special offer 108
Fig. 121. New design of the Comarch ERP Offer window 108
Fig. 122. New design of the RPA Robotisation window 109
Fig. 123. New parameter on the (W)ZWM document 110
Fig. 124. Change in the presentation of stock in the Warehouse column for WMS-enabled warehouses 115
Fig. 125. Centres on the related commodity form 116
Fig. 126. Related commodities shown on the commodity (article) card 117
Fig. 127. Related commodities visible when adding commodities to a document 117
Fig. 128. Setting up credit limit support on the Comarch POS branch configuration window 118
Fig. 129. Configuration of payment methods at the POS for the credit limit support 119
Fig. 130. Parameters for including documents without payments and orders in the limit 119
Fig. 131. Parameters defining the action after acceptance of a document exceeding the limit 120
Fig. 132. Setting up a payer on the counterparty’s card 120
Fig. 133. List of acquirer’s limits on the counterparty’s card 121
Fig. 134. Assigning an acquirer to a counterparty 121
Fig. 135. Parameters for creating cash register reports 122
Fig. 136. List of dictionary names retrieved from wszystko.pl account to which the connection was made 124
Fig. 137. Settings for integration activities on the wszystko.pl branch 125
Fig. 138. Button to remove the wszystko.pl connection on the branch card 126
Fig. 139. Category tree on the [wszystko.pl] tab of the commodity list 127
Fig. 140. Category form of the lowest level of the category tree, view after “using” a category in the System 128
Fig. 141. New commands on the [wszystko.pl] tab of the commodity list 129
Fig. 142. Data for wszystko.pl integration on the commodity card 130
Fig. 143. Setting the value for the parameter type: multiple-choice list 131
Fig. 144. Presentation of the value of a parameter type: multiple-choice list 132
Fig. 145. Message indicating that the allowed number of values for the parameter has been exceeded 132
Fig. 146. Presentation of the value of a parameter type: range 133
Fig. 147. Places from which the name and description are taken for the offer 135
Fig. 148. Various options for updating the offer on the portal 137
Fig. 149. Various options for publishing an offer 138
COMARCH ERP
Unauthorised distribution of this whole publication or its part in any form is prohibited. Making copies by photocopying, photographing, or copying on a film, magnetic or other medium, causes copyright infringement of this publication.
Copyright © 2022 COMARCH
All rights reserved.