Below, there is a description of activities to be executed during the update of Comarch ERP Standard to the most recent version. Additionally, changes that might have effect on current functioning of the system, are listed.

Updating Comarch ERP Auto Update to the most recent version on all workstations.

1. It is necessary to start Comarch ERP Auto Update Service service (if it is not activated)
2. To download new Agent version, it is necessary to be connected to update.comarch.com server on a relevant port depending on the language version.
   1. Polish/English version: port 8466
   2. German version: port 8539
   3. French version: port 8460
3. The Agent will be automatically downloaded to the download directory (normally, it is C:\Comarch ERP Auto Update\Downloads\AgentVersions\)
4. After restarting Comarch ERP Auto Update, it is possible to update it to the recent version. It will be updated to the following version:
   1. Polish/English version to version version_number.xxxx.1 (e.g., 2019.0.3665.1)
   2. German version to version version_number.xxxx.2
   3. French version to the version version.number.xxxx.3
5. Agents update should be carried out in accordance with the hierarchy, starting with the main agent
6. Agents update should be carried out on all workstations: Headquarters and Retail POS
7. Before installing a new version, it is necessary to complete configuration (if they have not been completed before) of Headquarters and Comarch Retail components, by specifying the names of configuration and company database (Configuration → selection of a relevant component on the tree of products → [Configuration] button in the main menu).

Updating Comarch ERP Standard/Comarch Retail version by means of Comarch ERP Standard on all workstations

It is recommended to carry out updates in the following orders:

• Headquarters Server
• Headquarters Workstation
• Comarch Retail

Conversion of values of properties and of attributes

When updating Comarch ERP Standard, a message informing about the necessity of executing conversion of database (both company and configuration) properties. Such conversion can be also started manually.

Before starting the conversion of properties, it is necessary to configure it. It can be done by means of [Configuration] button which is available in Component section or by clicking with the right mouse button on a component item on the list and selecting Configuration option.

Then, in Feature and Attribute Conversion Configuration section, it is possible to go to the configuration of properties and attributes, by selecting [Configure] button.

In the window of values conversion configuration, it is necessary to select language culture of entered values. It can be defined for each object separately or for all objects at the same time. 5 languages are available: Polish, English, German, French and Spanish.

Such configuration can be performed only on the main agent and for the child agents it is retrieved from the main agent.

Update process

After selecting the option Download and install, in the main window of Comarch ERP Auto Update, the update of the system to the current version will be performed. The application allows for updating the whole environment – Headquarters along with POS workstations from the level of the Headquarters.

The license validity is also checked in the Comarch ERP Auto Update tool. However, the information regarding license validity date is displayed only for information purposes, which means it does not block the update of the product to a newer version.

Company structure conversion

During the conversion to version 2015 of the company database Comarch ERP Standard, a question regarding conversion of rights structure is displayed. After reading the displayed text, it is necessary to select one of available options:

Leave the main node unchanged – existing warehouses, VAT accounts and cash-bank registers after conversion will be marked as dedicated for the main company.

Convert the main node to center of Company type – existing warehouses, VAT accounts and cash-bank register after conversion will be automatically attached to a created center of company type and it will not be possible to use them for operational work in the main company (parameter Dedicated for parent company is unchecked on these objects and blocked).

Consents conversion

In the 2018.1. version of Comarch ERP Standard functionalities supporting handling personal data stored in the system were introduced. During the first conversion of the company database of the Comarch ERP Standard system to version 2018.1. at least, a window allowing for selecting conversion method of consents stored in the system is displayed. There are two options available – Convert consents to the new format according to set parameters and Remove previously registered consents during database conversion.

After selecting the option Convert consents to the new format according to set parameters, the following window is opened:

Confirming the above window will save in the application memory the information provided in the above-mentioned fields and will begin the installation process On the basis of the content of these options, a pattern of consents will be generated and previous consents for receiving marketing information will be replaced by the consents in the new format. After assigning the title and the content, converted consents will be added to the Marketing category.

Selecting the option Remove Previously Registered Consents will save the selection in the application memory and will begin the installation process.

Availability of dimensions in a multi-company structure

After converting the system from versions lower than 2016.5.5:

1. On all secondary dimensions and dimension elements, in the Owner field, the value All is set. It is possible to leave this setting or set a selected element as available only for a specific company.

1. On the level of the dimension element, it is necessary to verify the association with the account.

To increase the ergonomics of user’s work, on the list of dimensions two additional columns visible on the list of hidden columns were added: Owner and Account. In the Owner column the company being the owner of the element of analytics subdimension and in the Account column, the account selected on the element form or on the subdimension form in a given company, is displayed.

Because it is possible to determine an owner on the form of analytical dimension’s elements, only elements, for which the company, to which an operator is logged on, or the value All is selected as owner, are displayed on the list of analytical dimension values.

Analytical description percentage value precision

From version 2018.1.1 the percentage value of an analytical description is saved and displayed with a higher precision, that is to four decimal places. The increase of the precision is caused by the necessity of eliminating discrepancies between the amount value and the percentage value of the analytical description.

The calculation of the value of an analytical description with precision to four decimal places is executed for new records only. During the conversion of the database to version 2018.1., the percentage values of the analytical descriptions on previous documents are not recalculated in accordance with the new precision. Only zeroes are added in order to maintain the format compliance.

In order to update analytical description percentage values on documents already added to the system, for versions lower than 2018.1., it is necessary to execute e on the database a script for required data interval.

New licensing configuration

During the update of Comarch ERP Auto Update to version 2016.2, a new product to install, named Comarch ERP Key Manager, is automatically added.

In order to properly install the Key Manager, first it is necessary to configure the product. To do so, it is necessary to open Configuration window.

Then, appropriate data regarding the product must be completed, that is SQL instance, SQL user (a user added to the server role Sys_admin is required), data regarding license key, cClient ID, PIN, Key number.

After entering the correct data in the configuration window, it is necessary to install the product.

Verification of licensing settings

The configuration of licensing settings can be performed with the use of the configuration tool. The licensing settings are available in the tab License key. Here, it is necessary to provide the name of the server on which the Comarch ERP Key Manager product is installed and license key.

Comarch ERP Standard log-on – new license server selection window

During the first access to Comarch ERP Standard after migration, a window for selecting license server is opened. Here, the user must complete the name of the key server and the key number.

The name of the key server is saved in the Altum.exe.config file, in section <add key=”LicenseServer” value=”SERVER_NAME />. Particular license keys are saved in the database along with information regarding operators.

From the level of the list of users, it is possible to define keys for all operators existing in the system.

Changes to service names

From version 2015.0, names of services have been standardized and changed.

Timeout settings

After the version update, timeout value in the system configuration is set to default value, that is 1 hour. The settings regarding timeouts are available in the menu System → Configuration → Computer.

BPM settings migration verification

To verify the migration, it is necessary to launch BPM Configuration tool. Detailed description of the configuration can be found in BPM category.

Update of processes

After migrating the system to a higher version, it is needed to update the version of modified processes to a given system version. The processes can be updated in BPM Process Editor. To do so, it is required to remove the current standard processes from the editor and import new process definitions provided along with the new program version.

Verification of permissions to accounting objects

In the 2015 version, accounting records in the multicompany model is conduced within separated accounting books of individual entities. Accounting data can be previewed and entered after selecting a company within the accounting period and chart of accounts defined for it.

1. Accounting periods, ledgers and chart of accounts

Accounting periods, ledgers and charts of account are separated for each structure center of Company type. During the conversion from the previous version, the user can select two different conversion methods:

• the current center of company type remains the main node. In such case, ledgers and accounts are assigned on the level of the main company or the main node (which corresponds to the company structure prior to the 2015 version).
• related to distinguishing additional center of Company Ledgers and accounts are assigned on the level of a subordinated company and are not visible from the level of the main node/main company.

After migration to version 2015, it is necessary to verify the settings of accounting periods, ledgers and chart accounts for particular companies (main node or subordinated company).

After conversion, also the availability of accounts in particular centers must be verified – by default, they are available in all centers of a given company.

2. Journal entries, contra entry, accounting notes, opening balance

From version 2015, displaying of accounting documents is subject to standard limits basing on the field Owner on the document and rules regarding sharing a document of a given type (tab Visibility in the document definition).

On the form of these objects, field Owner is available. During the conversion from the previous version, the user can select two different conversion methods:

• the current center of company type remains the main node. The above mentioned objects are assigned on the level of the main company or the main node (which corresponds to the company structure prior to the 2015 version).
• related to distinguishing additional center of: Company type. The above mentioned objects are assigned on the level of a subordinated company and are not visible from the level of the main node/main company.

Additionally, when during the conversion, on the definition of the above mentioned accounting objects, visible in the rights structure, the visibility in all centers of the company structure is set for each center. Thanks to that, the conversion does not cause taking away the visibility from the users who previously were able to see those accounting objects. After the migration to version 2015, the user must verify the visibility of the above mentioned accounting objects for particular centers of the company structure.

3. Posting schemes, recurring posting schemes, statements

The availability of posting schemes, recurring posting schemes and statements can be configured in menu Configuration → (Company Structure) → Objects Availability. The above mentioned accounting objects are available in a specific company and in subordinated centers of its structure. After the migration to version 2015, the user must verify the visibility of the above mentioned accounting objects for particular centers of the company structure. In this place, the user also indicates the default posting scheme valid in a given center when posting a specific document type.

4. VAT accounts

On the VAT account definition, parameter Dedicated for parent company has been made available. During the conversion from the previous version, the user can select two different conversion methods:

• the current center of company type remains the main node. In such case the parameter will be checked in all VAT accounts.
• related to distinguishing additional center of Company In such case the parameter will be unchecked in all VAT accounts.

During the conversion, a full list of VAT accounts is assigned to the definition of each defined company structure center.

After the migration to version 2015, the user must verify the availability of VAT accounts for particular centers of the company structure and the settings of the parameter Dedicated for parent company.

5. Cash-bank accounts

On the cash-bank account definition, parameter Dedicated for parent company has been made available. During the conversion from the previous version, the user can select two different conversion methods:

• the current center of company type remains the main node. In such case the parameter will be unchecked in all VAT accounts.
• related to distinguishing additional center of Company In such case the parameter will be checked in all VAT accounts.

After the migration to version 2015, the user must verify the availability of cash-bank accounts for particular centers of the company structure and the settings of the parameter Dedicated for parent company.

6. Cash-bank deposits and withdrawals

During the conversion from the previous version, the user can select two different conversion methods:

• the current center of company type remains the main node. In such case, the ownership of cash-bank deposits and withdrawals will remain on the level of the parent company/parent node (which corresponds to the structure valid prior to the 2015 version).
• related to distinguishing additional center of Company A subordinated company will become the owner of cash-bank deposits and withdrawals.

Additionally, during the conversion, on cash bank deposit/withdrawal definitions which are visible in the rights structure from the level of the company, the visibility is set in all centers subordinated to that company, so that, after the conversion, the visibility is not taken away from those users who could previously see the transactions. Thus, the user must verify permissions regarding the visibility in company centers.

Verification of permissions to Tax return object.

In the version 2015, the system of permissions has been extended by Tax return object type and the possibility of limiting permissions of an operator group to modifying, adding, deleting and reading a tax return. All operator groups have received full authorizations, by default.

After the migration to version 2015, the user must verify permissions to VAT tax return for particular operator groups.

Adapting user’s layouts

Interface changes are implemented between versions of Comarch ERP Standard system. After the migration, it is required to adapt customized user forms to the new version. Detailed description of layout configuration can be found in category Interface and customization.

Migration of Comarch ERP Standard user’s profiles

Profiles of the ribbon in Comarch ERP Standard system are not automatically converted, except for Standard profile. All other profiles must be converted with the use of Conversion Manager tool. The tool is available in Database Manager, in Configuration tab.

Detailed description of the conversion can be found in article Conversion Manager.

Default voucher sort

In case there are several sorts of vouchers of type Internal released, marked as Active and none of them is marked as Default, after database conversion to version 2016.5, one of them will be marked as Default. The user should verify whether the assigned setting corresponds to their expectations and whether the selected sort is used by default in the system and marked as Default.

Comarch ERP e-Shop version migration

When migrating Comarch ERP Standard/Comarch Retail system, it is also mandatory to migrate
Comarch ERP e-Shop product. Before executing the migration of both system to a newer version, it is recommended to synchronize data (such as orders or customers/vendors) from Comarch ERP e-Shop to Comarch ERP Standard. The synchronization should be started only after both products are migrated to the appropriate version.

For Comarch ERP e-Shop in online version, it is necessary to send migration request to the technical assistance (through SOZ system). In the request, Comarch ERP e-Shop should be selected as product.

For Comarch ERP e-Shop in stationary version, it is necessary to launch WAMC tool and execute migration with the use of it.

Migration of Comarch B2B version

When migrating Comarch ERP Standard/Comarch Retail, it is also necessary to install a dedicated version of Comarch B2B product.

Migration of POS1.0 to POS2.0

Migration of Comarch POS to version 2.0 is possible only if the POS workstation in version 1.0 is attached to the company database of the Comarch ERP Standard/Retail headquarters. It means that it is not possible to execute migration to POS2.0, if the POS1.0 workstation is attached to Comarch Retail Backoffice.

Detailed description of installation of Comarch POS 2.0 application can be found <<here>>.

During the first start of Comarch POS2.0 and DS service, the synchronization of all indispensable objects to POS2.0 will be executed.

To switch from Comarch POS1.0 version to Comarch POS2.0 the user must change the value of parameter Version next to selected workstation in Comarch ERP Standard.

To do so, it is necessary to open company configuration: Configuration (Company structure) Company. On the form, select POS Workstations tab. Next to each POS workstation, in column Version, there is a number of Comarch POS version number. After selecting on the list POS workstation which is supposed to be updated to version 2.0., it is necessary to click on [Edit] button.

In POS workstation edition, in Version field, option POS2.0 must be selected.

During the change of POS workstation from version 1.0 to 2.0 the system displays the following message: „Do you want to attach definitions of reports for the given POS workstation version automatically?”. The user must confirm the message and save the configuration of the workstation and the configuration of the company.

License reset for POS2.0

If POS workstation code was saved with the use of lower cases, e.g., Pos01, then, after the migration to Comarch Retail in version 2017.5, it will not be possible to retrieve the license for such POS workstation. For POS workstation with such codes, it is necessary to reset the license key for 16140 POS license. It can be done by sending a request to Technical Assistance.

Fiscal profile in POS2.0 configuration

After migration to version 2017.5, the user must verify whether in POS 2.0 workstation configuration in Comarch ERP Standard, a correct fiscal profile is set. If no value is set for the field, printing on fiscal printer on POS workstation will not work.

Upgrading TLS protocol to version 1.2

Due to security reasons, servers administrators can turn off handling of TLS protocol in version 1.0 and 1.1., both for the server functions and for the client. In such situation, it might be necessary to update Microsoft SQL Server instance to an instance supporting TLS 1.2. protocol.

1.Installation of version TLS 1.2 for SQL Server service

It is necessary to verify whether the held version of SQL server supports TLS 1.2. To do so, the user should verify whether their version of SQL Server supports TLS 1.2 protocol using the appropriate table available on Microsoft website: https://support.microsoft.com/pl-pl/help/3135244/tls-1-2-support-for-microsoft-sql-server

Component SQL Server Native Client must be installed for appropriate server version. Its installation wizard can be found on Microsoft website: https://support.microsoft.com/pl-pl/help/3135244/tls-1-2-support-for-microsoft-sql-server

2.Turning on and turning off TLS version

To activate or deactivate the handling of TLS protocol version on the server, it is necessary to open Register Editor (regedit.exe) and check if in path:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols,

there are keys named “TLS.10”, “TLS 1.1” and “TLS 1.2”. If such keys don’t exist, they must be created. Each above mentioned key should contain two keys: Client and Server.

Keys Client and Server should contain three values each:

• (Default)
• DisabledByDefault (DWORD type)
• Enabled (DWORD type)

If a given protocol version is to be disabled, it should contain values: DisabledByDefault = 1 and
Enabled = 0.

If a given protocol version is to be enabled, register key should contain values: DisabledByDefault = 0 and Enabled = 1.

Equipment as fixed asset

From versions 2019 equipment is a fixed asset of Equipment type. In new location, equipment can be found in menu Accounting → Fixed Assets, in Main/Equipment tree.

Data from tables that currently store information regarding equipment, that is [Equipment].[Equipment] and [Equipment].[EquipmentGroups], have been moved to new tables in FixedAssets and SecFixedAssets scheme. Tables in Equipement schemes will temporarily remain on the database, but they will not be used.

The structure of equipment groups will be transferred to new tables. Each of transferred groups will have its current name and will have Equipment type assigned. The value of depreciation method will be set to Not subject.

The following fields will be transferred onto new equipment forms:

• Code – field with unique value. Here, it is necessary to enter the equipment name. If there are several instances of the same name, subsequent numbers preceded by underscore are assigned, e.g., Name_1
• Name
• Inventory Number
• Type
• Location of Use
• Custodian
• Acquisition Date
• Date of Receipt
• Acquisition Document
• Date of Disposal
• Disposal Document
• Disposal Document
• Reason for Disposal
• Initial Value
• Attributes and Attachments – during the conversion, those objects are attached to Fixed Asset objects corresponding to them

Deletion of Sales.DocumentSubitemRelations table

In archive system version, the relation between a subitem and an item is saved in Sales.DocumentSubitemRelations table. In current system version, the reference to Sales.Items element is saved directly on the subitem, in Sales.Subitems Table.
In version 2019.5 table Sales.DocumentSubitemRelations has been removed. All add-ons based on this table, will not work once the system is updated to version 2019.5.

Modification of queries

Currently, instead of a typical joint:

SELECT TOP 1 *

FROM SecSales.Headers SSH

INNER JOIN Sales.Items SI ON SI.HeaderID = SSH.ID

INNER JOIN Sales.DocumentSubItemRelations DSR ON DSR.ItemID = SI.ID

INNER JOIN Sales.Subitems SSUB ON SSUB.ID = DSR.SubItemID,

it is necessary to join in the following way:

SELECT TOP 1 *

FROM SecSales.Headers SSH

INNER JOIN Sales.Items SI ON SI.HeaderID = SSH.ID

INNER JOIN Sales.Subitems SSUB ON SSUB.ItemID = SI.ID

Objects requiring verification

All authorial solutions (dedicated for Client) available, among others, in the following objects, must be verified and modified in accordance with this example:

• Extensions
• Printouts
• Posting schemes
• Analytical descriptions
• SQL attributes
• Tax returns
• User’s filters
• BPM processes using SQL activities
• Views
• Procedures
• Triggers

Places in database (e.g., printouts, posting schemes, extensions, views, procedures etc.) in which the table occurs
can be verified with the use of the following script:

;with AllFunc as(

SELECT

o.object_id

,s.name as 'Schema'

,o.name as 'Table'

,m.definition

,o.type_desc

,dbo.regexMatch(m.definition, N'DocumentSubitemRelations',1)

as IsPatternMatched

--,*

FROM sys.sql_modules m

INNER JOIN sys.objects o

ON m.object_id=o.object_id

INNER JOIN sys.schemas s

ON s.schema_id= o.schema_id

)

select * from AllFunc

where IsPatternMatched=1

order by 'Schema','Table'

To verify the occurance of the table in BPM activities, it is possible to use the following query:

SELECT

T.InternalName AS “Process name"

,Charindex( 'Sales.DocumentSubItemRelations',Cast(Cast(Data AS xml) AS

nvarchar(max)),0) AS “Location of use"

,Cast(Data AS xml) AS “Data"

FROM Workflow.FileItems FI

JOIN Workflow.WorkflowDefinitions WD ON FI.FolderItemId = WD.FileId

JOIN Workflow.Workflows W ON WD.WorkflowId = W.WorkflowId

JOIN Workflow.Translations T ON W.TranslationId = T.TranslationId

WHERE Charindex( 'Sales.DocumentSubItemRelations',Cast(Cast(Data AS xml) AS

nvarchar(max)),0)>0

Changes to address format

From version 2019.5 of Comarch ERP Standard system, the information regarding selected customer/vendor address on
a document, has been transferred from table  Sales.DocumentCustomers to table SecSales.Headers.

Changes to database

Two new columns have been added to table SecSales.Headers: Customer1AddressDataId and Customer2AddressDataId. During the conversion of the database, the information regarding selected customer/vendor address on a document is transferred to the above mentioned columns in accordance with the following scheme:

• values from column AddressDataId, from table Sales.DocumentCustomers will be transferred to column Customer1AddressDataId in table SecSales.Headers for rows which in the column CustomerTypId had value 0 or 2.
• values from column AddressDataId, from table Sales.DocumentCustomers will be transferred to column Customer2AddressDataId in table SecSales.Headers for rows which in the column CustomerTypId had value 1 or 3.

Modification of queries

Previously used joint necessary for selecting customer/vendor data address from a
document:

SELECT TOP 1 AD.*

FROM SecSales.Headers H

LEFT OUTER JOIN Sales.DocumentCustomers DC ON DC.DocumentId = H.ID AND

DC.CustomerTypeID IN (0,2) -- First customer

LEFT OUTER JOIN Address.AddressData AD ON AD.AddressDataId =

DC.AddressDataID

Must be replaced by:

SELECT TOP 1 AD.*

FROM SecSales.Headers H

LEFT OUTER JOIN Address.AddressData AD ON AD.AddressDataId =

H.Customer1AddressDataId -- First customer

Planned deletion of table Sales.DocumentCustomers

Table Sales.DocumentCustomers will be not deleted in version 2019.5. In future system versions, after finishing planned works in the area of Addresses and Customers/Vendors, the table will be deleted. Information regarding the date of table deletion and additional changes to the area will be provided before releasing the version containing the above mentioned modifications.

Addition of a fixed document type

In version 2019.5, a fixed type of document has been added – DocumentKindId. The type will allow to construct more efficient queries and replace previously used reference to DT.DocumentTypes.NamespaceEntry.

Changes to database

The following columns have been added to the database:

• DocumentTypes.DocumentKindId
• Headers.DocumentKindId
• DocumentHeaderRelations ChildDocumentKindId i ParentDocumentKindId
• Operations.DocumentKindId
• Dunning.DocumentKindId
• OpeningBalanceDocuments.DocumentKindId
• PlannedPayments.DocumentKindId

Modification of queries

DocumentKindId is a fixed id of document type (contrarily to DocumentTypeID), so it remains unchanged regardless of the database language. In new views/procedures, it is necessary to use constants of its value, analogically to the use of NamespaceEntry.

Instead of query:

SELECT HE.Id FROM SecSales.Headers HE

LEFT JOIN DT.DocumentTypes DT ON DT.Id = HE.DocumentTypesID

WHERE DT.NamespaceEntry IN

('Comarch.B2.Sales.Documents.SalesOrderManager','Comarch.B2.Sales.Documents

.PurchaseOrderManager')

It is necessary to use:

SELECT HE.Id FROM SecSales.Headers HE

WHERE HE.DocumentKindId IN /*(ZS/ZZ)*/ (11,10)

DocumentTypeId is not deleted anywhere, so all queries created with the use of it will function correctly. However, it is recommended to gradually modify existing queries and create new queries with the use of DocumentKindId to optimize the time of query executions. To generate correct DocumentKindId with NamespaceEntry, it is possible to use the following query:

SELECT 'DocumentKindId IN '

+'/*(' + dbo.GROUP_CONCAT(Code, '/') + ')*/ '

+ '(' + dbo.GROUP_CONCAT(DocumentKindId, ',') + ')'

FROM DT.DocumentTypes

WHERE NamespaceEntry IN

('Comarch.B2.Sales.Documents.SalesOrderManager','Comarch.B2.Sales.Documents

.PurchaseOrderManager'

When adding new document type (adding entry to table DT.DocumentTypes), in column DocumentKindId, it is necessary to set an id with value not lower than 1000, because these values are reserved for objects included in API. The ID can be generated with the use of the following query:

DECLARE @DocumentKindId INT

SELECT @DocumentKindId = ISNULL(MAX(DocumentKindId), 0) + 1 FROM

DT.DocumentTypes

IF @DocumentKindId < 10000 SET @DocumentKindId = 10000

If in the extension, standard documents are created, it is necessary to verify whether when adding them, DocumentKindId is assigned properly, in accordance with the Id specified in DT.DocumentTypes.DocumentKindId for a given document type.

Changes to API

Enum DocumentKind has been transferred from Comarch.B2.Sales.Interfaces.Documents to Comarch.B2.Core.Interfaces and completed with all document types (previous values are maintained). In the main business entity (Comarch.B2.Sales.Interfaces.Documents.Document), virtual property DocumentKind was added, which was overloaded in entities which inherit from it, so that it can return a value appropriate for a given entity.

The following mappings of DocumentKind enum are available:

• to DT.DocumentTypes.NamespaceEntry, for example
  var namespaceEntry = DocumentKind.SalesInvoice.ToNamespaceEntry();
• from DT.DocumentTypes.NamespaceEntry np.
  var documentKind = DocumentKindExtension.ParseNamespaceEntry
  (“Comarch.B2.Sales.Documents.SalesInvoiceManager”);
• to DT.DocumentTypes.Id, for example
  var documentTypeId = PermissionService.GetDocumentTypeId
  (DocumentKind.SalesInvoice);
• from DT.DocumentTypes.Id for example
  var documentKind = PermissionService.GetDocumentKind(header.DocumentTypeId);

.Net Framework migration

Comarch ERP Standard system, from 2019.5 version will be compiled basing on Microsoft .NET Framework in version 4.7.2. It means that in order to ensure the correct functioning of created extension with the newest system version, it is necessary to execute migration to Microsoft .NET Framework 4.7.2 version.

Changes to libraries

In version 2019.5, libraries PostSharp, PstSharp.Sdk, PostSharp.Sdk, PostSharp.Sdk.XmlSerializers, PostSharp.Settings and BFsharp.AOP will be not used anymore.
They have been replaced with libraries MethodBoundaryAspect and PropertyChanged and are used in the internal infrastructure. During the migration, it is possible to delete libraries which are not used anymore.