1              Information about support deliveries

The “Query support deliveries” application in the support system allows you to download directly from Comarch ERP Enterprise the support deliveries with their corresponding delivery documentation as well as further information.

The following types of support deliveries are relevant for you:

• RFR

This type of support delivery comprises a software upate or a file delivery as well as the corresponding delivery documentation.

• INF

This type of support delivery is used to provide FAQ-like information in a document.

• LNG

This type of support delivery is used to deliver language updates that can be installed in addition to German (de).

• 900
  This type of support delivery comprises adaptors for the communication with third-party systems.
• APP
  This type of support delivery comprises installable Apps as well as the corresponding delivery documentation.

The available support deliveries are displayed in the “Query support deliveries” application according to the selected release, delivery, or delivery date. You can search for support deliveries and download their content. You can also find out whether new support deliveries are available. The application keeps a log on who has displayed which information or downloaded which software update, and when.

Note:
You need appropriate authorizations to download files. Please refer to the application documentation of “Support deliveries query”. If the relevant authorization is missing, please contact your Comarch support partner.

2              Installation of software updates

Follow the instructions given in the documentation “Introduction: Software Logistics” to install the software updates that are contained in the support deliveries. If there are deviating instructions to be followed, they are provided in chapter “Information about CEE630PB-Fix25”.

Preparing the installation

Please read the info texts accompanying the support delivery. Before installing the software updates, you must carry out a data backup of the database contents and the file system.

Make sure that all databases of the system are connected with the message server or with the ERP System Application Server (SAS) that you use for the upgrade. Shut down the SAS of the system before installing the software updates.

3              Information about CEE630PB-Fix25

With the delivered software updates, a Comarch ERP Enterprise system that has version CEE630PB-Fix24 will be upgraded to CEE630PB-Fix25.

3.1        Installing support deliveries

The following sections describe the special features for installing the support deliveries of this delivery.

If the source system has a state that is between CIS620PA and CIS620PB-Fix11, you can use the manual update procedures described below to upgrade a Comarch ERP Enterprise based system to CEE630PB.

Further information is provided in INF-000155.

To install the support deliveries, please use the documentations “Introduction: Software Logistics” and “Using Tools and Troubleshooting Help.”.

3.2        Cumulative installation of support deliveries

Code status CIS620PA is required for the release upgrade. It is not possible to install Comarch ERP Enterprise 6.2 and Comarch ERP Enterprise 6.3 at the same time. Support deliveries for Comarch ERP Enterprise 6.3 can be installed cumulatively. Further information about the cumulative installation are provided in INF-000228.

3.3        Parallel or sequential installation

If you use the tool insrfr to install the support deliveries, you must choose the sequential (installType:3) installation type. Alternatively, you can first install the system code support deliveries manually and install the application code support deliveries afterwards.

3.4        Problems during the installation

If a problem arises during the installtion of support deliveries, you can refer to INF-000155 “Behebung von Installations-Problemen von Supportauslieferun­gen” which contains information about possible causes and about instructions on how to solve the problem.

• Rework after installation

4.1        Data updates

No data updates have to be carried out.

4.2        Batch data updates

No data updates have to be carried out.

5              Contained changes and extensions

5.1        Application development

RFR-016580 Ergonomics

Update of the Polish language user interface.
The installation does not affect the texts. You obtain the translations in support deliveries from the support center.

RFR-016580 Correction

Framework: Base
Application: n.a.
View: n.a.
Action: n.a.
com.cisag.app.general.item.log.ItemPropertyVirtualTable
Category: Unexpected behavior

Problem: Due to the data model change for item characteristics, the virtual table no longer worked.

Correction result: The virtual table works as expected.

RFR-016580 Ergonomics

Update of the English language user interface.
The installation does not affect the texts. You obtain the translations in support deliveries from the support center.

5.1.1  Base

5.1.1.1      Base – General

RFR-016580 Correction

Frameworks: Purchasing, Sales
Applications: Purchasing bonus settlement, Sales bonus settlement
Action: Execute
Category: Exception

Problem: If the customizing does not contain a valid “supplier invoice type” (purchasing) or “sales order type” (sales) an exception occurs during the try to execute the bonus settlement.

Correction result: Now the exception does not occur any more.

RFR-016580 Correction

Frameworks: Purchasing/Sales
Applications: Purchase price lists, Sales price lists
Action: Import correction mode
Category: Exception / Unexpected behavior / Ergonomics

Problem: If the import file contains a wrong organization an “java.lang. IllegalArgumentException: organization does not exists! 000000000000000000000000000000F0” will be thrown so that the application closes with this error.

Correction result: Now – in analogx to the error messages within the import error file – a message will be send instead.

Hint: Please note that application does not support a correction of the organization – so, you have to correct the import source data.

5.1.1.2      Classifications

RFR-016580 Correction

Framework: Base
Application: Classifications
Action: Change organization
Category: Exception / Unexpected behavior / Ergonomics

Problem: A change of the organization does not refresh the complete user interface (in contrast to the load/refresh action).
In addition to that – as following problem – in case of an organisation without relevant data (e.g. without sales data) an “IllegalStateException: Not initialized!” occurs during the try to create a new node.

Correction result: Now the refreshment will be performed as expected.
Please note also the following further changes: – If the current classification has no data dependent on organizations, any changed data is no longer simply discarded; instead, only the organization is changed.
– If the previous and the new organization have the same maintaining organization, any changed data is no longer simply discarded; instead, only the organization is changed and the title of the application will be refreshed.
– If the old and new organizations have different maintaining organizations or the new organization cannot be used and data has been changed, the usual question as to whether you want to discard your changes or not is now asked before switching. While the confirmation dialog is open, the old organization is used as usual. If you confirm that you want to discard the changes, the data will be refreshed with the new organization – an error message may then appear if the new organization cannot be used for the type of the current classification.
– “Open empty” works now as expected

5.1.1.3      Contracts/RFQs/Quotations/Orders

RFR-016580 Correction

Frameworks: Purchasing/Sales
Applications: Purchase orders, Sales orders
Action: “rescheduling” actions
Category: Unexpected behavior / Ergonomics

Problem: The sales order and purchase order “rescheduling dialog” were using by mistake for the “delivery date” title (“label”) the same field guid (“0260A78B193E1E10A6798464963A0000”).

Correction result: Now the purchase order “rescheduling dialog” uses a new guid (“01A05A3B5C0F331092A20B861BEE0000”) for the “delivery date” title – so both guids are now different.

5.1.1.4      Item characteristics

RFR-016580 Correction

Framework: System Management
Application: Import data
Action: Import “Item-characteristics assignments”
Category: Performance

Problem: The import of “Item-characteristics assignments” should be done ordered by classification (not by item). But if even if the source data is ordered in that kind the data for a classification will be saved and reloaded after 16 imported source instances (hard coded value). Because “reload” performs a load of all persistent item assignments (ItemPropertyCollection instances) the import performance might be to low in some cases.

Correction result: If you have enough memory you can use for example now “set com. cisag.app.general.item.log.ItemPropertyBIController.BlockSize=1000” to increase the value.

Hints:
– If no value or an invalid value (<=0) is specified the default value 16 will be used as before.
– If the classification changes the data will be saved and reloaded even if the “block size” is not reached.

5.1.1.5      Partner templates

RFR-016580 Correction

Framework: General
Application: Partners
View: n.a.
Action: Create from template
Category: Unexpected behavior

Problem: A newly created partner couldn’t get stored, although no errors are displayed.

Correction result: From now storing a newly created partner will work as expected.

5.1.1.6      Partners

RFR-016580 Correction

Framework: General
Application: Partners
View: Base view
Action: n.a.
Category: Exception

Problem: It was possible to move the field “Date of birth” from the tab “person data” to other components of the application. Doing that, the field would be editable and enabled for partners, which aren’t a person resp. which could not have a date of birth. In that case an exception occurred when the user wanted to open the calendar dialog of this field.

Correction result: From now the visual component “person data” won’t be customizable any more.

5.1.2  Calculation

RFR-016580 Correction

Framework: Calculation
Application: Product cost calculation
View: n.a.
Action: Update sales price
Category: Unexpected behavior

Problem: When line for Sales price is not specified, error leads to wrong field ‘Price1’ instead of ‘Sales price’ field.

Correction result: When line for Sales price is not specified, error leads to correct ‘Sales price’ field.

5.1.2.1      Calculations

RFR-016580 Correction

Framework: Calculation
Application: Cockpit: Purchase items
View: n.a.
Action: Generate calculations…
Category: Unexpected behavior

Problem:
A.
Context: A calculation schema has set: “Supplier origin” = “Alternative supplier according to allocation data”. Some items have set a main supplier in application “Items” -> view “Planning data”. They do not have set an alternative supplier. Additionally each item has a supplier view specified with main supplier of planning view.
From “Cockpit: Purchasing Items” action “Generate calculations..” is started. In the dialog to this action no supplier is specified.
Result: Purchasing specific values for calculation are retrieved from main supplier according to planning data of calculated item. But it is expected that purchasing specific values are retrieved from purchasing data of calculated item as calculation schema requires alternative supplier which is not specified in planning data. Also purchase price will be retrieved from item + supplier if a price at this level is specified.
Please note: If alternative supplier is defined in planning data but has no supplier view defined in application “Items” purchasing specific values must also be retrieved from purchasing view. But purchase price may be retrieved from alternative supplier if one is specified at level item + supplier.
B.
Field “Supplier origin” is only editable if field “Valuation price” = “Price from price listing” is set. This is an unnecessary limitation.
Please note: field “supplier” is only editable if “Supplier origin” = “Manually defined supplier” is set.

Correction result:
A.
In above described context purchasing specific values are retrieved from purchasing data of calculated item. Also purchasing price is retrieve from item level.
B.
Field “Supplier origin” is editable without restriction.

5.1.3  Inventory management

RFR-016580 Correction

Framework: Inventory Management
Application: Availability inquiries
View: n.a.
Organization change
Category: Exception

Problem: If the organization was changed before anything was loaded an exception could be caused.

Correction result: The organization can be changed as expected.

5.1.3.1      Inventory count

RFR-016580 Extension

Framework: Base
Application: Number ranges
View: n.a.
Action: Validate
Field/Column: Number length
Category: New action

Description: The allowed number length for inventory counts was increased to ten.

5.1.3.2      Loading units

RFR-016580 Correction

Framework: Inventory
Application: Import data, Export data
Filter: com.cisag.app.shipping.obj.UnitLoad, com.cisag.app.purchasing.obj.ReceiptOfGoods, com. cisag.app.sales.obj.ShippingOrder
Action: Import data, Export data
Category: Performance

Problem: The filter definitions of the BO’s com.cisag.app.purchasing.obj. ReceiptOfGoods and com.cisag.app.sales.obj.ShippingOrder were to big and needed to much time to load.

Correction result: From now the filters will not contain the associations “UnitLoad->Details->UnitLoadReferences” any more. Moreover the Integer-Systemproperties
– com.cisag. app.shipping.unitload.log.UnitLoadExportControllerPackagingDepth
– com.cisag.app.shipping.unitload.log. UnitLoadImportControllerPackagingDepth
are added. With these properties it’s additionally possible to reduce the supported packaging depth of loading units to a value less than 5 (which is the default value). This will reduce the filter size massively.

5.1.3.3      Loads

RFR-016580 Correction

Application: com.cisag.app.shipping.shippingload.log. ShippingLoadReorganization
Method: n.a.

Description: From now ‘shipped’ shipping loads could be marked for deletion in the application ‘Shipping loads’ and the application ‘Cockpit: shipping loads’. A new backround application was created to reorganize marked shipping loads.

RFR-016580 Correction

Framework: Inventory
Application: Shipping loads
View: Deliveries
Action: Post detail from editor (without validate)
Category: Exception

Problem: An exception occurred when posting a detail line from the editor to the list if the validation is deactivated and the data of the posted detail line is not valid.

Correction result: From now, as expected, the invalid detail line will be added to the list in that case.

5.1.3.4      Receipts of goods

RFR-016580 Correction

Class: com.cisag.app.inventory.receipt.log. ReceiptOrderAssignmentValidation
Method: Constructor, #validate(ReceiptDetail, ReceiptDetail, boolean), #validate(ReceiptDetailOrderAssignment), #validateDelete(ReceiptDetail persistentDetail)

Description: The declaration of the class, constructor and the listed methods is changed from ‘package private’ to ‘protected’

5.1.3.5      Warehouses

RFR-016580 Correction

Framework: Inventory Managment
Application: Warehouses
View: n.a.
Import changes of the inventory owner group
Category: Unexpected behavior

Problem: Import changes of the inventory owner group members were always denied.

Correction result: The members of an inventory owner group can be updated per import as expected.

5.1.4  Planning

RFR-016580 Correction

Framework: Planning
Application: Material requirements planning
View: n.a.
Action: Transfer planning data and execute planning, Update planning data and execute planning, Re-execute planning
Category: Unexpected behavior

Problem: Material requirements planning took a long time, especially when a lot of secondary demands were generated during planning of multiple sites at once and especially when forecasts were enabled.

Correction result: Material requirements planning is faster, especially planning multiple sites together and planning with forecasts.

5.1.4.1      Material requirements planning

RFR-016580 Correction

Framework: Planning
Application: Material requirements planning
View: n.a.
Action: all planning actions
Category: Unexpected behavior

Problem:
A: When an item was planning with delivery calendar and a recommendation was created for a delivery date, only the demands to the next delivery date were included, even in case the item had a demand coverage time range configured that should require to cover also demands after the next possible delivery date.
B: The planning automatically extends the demand period by non working days that immediately follow the currently planned day. In case a demand coverage time range is also configured, it also started immediately after the currently planned date, also covering the demands of the non-working days following the planning day. Thus, the demands of the extended planning period were counted twice, resulting in too high recommendations. This problem can only appear in case there are demands at non-working days.

Correction result:
A: After the planning decides that a recommendation is necessary considering the demands until the next possible delivery date, it will additionally find demands after the next delivery date until the end of the demand coverage range and include them into the recommendation quantity.
B: The demand coverage time range now starts AFTER the extended demand period of the planned day, so demands after the planned day in the extended demand period are not counted twice.

5.1.5  Production

RFR-016580 Correction

Framework: Production
Application: Reorganize production orders
View: n.a.
Action: n.a.
Category: Exception

Problem: A production order is reorganized even if there exists a parent or child production order referencing it, that would not be reorganized because of voucher chain dependencies.
This can lead to all sorts of other problems, like Exceptions when such a referenced order is edited.

Correction result: When checking whether a tree of production orders can be reorganized, it is also checked if certain voucher chain references prevent reorganization of the po.

5.1.5.1      Product configuration

RFR-016580 Correction

Framework: Production
Application: Product configuration rules
View: all views
Action: switch view
Category: Unexpected behavior

Problem: When user wanted to switch to a different view after data in the header was changed, a dialog was opened, where the user had to confirm the switch in order to not have the changes lost, when in fact, no header data is deleted by switching the view.

Correction result: No dialog is displayed when switching views after changing the header data. It will still appear when details are changed, as intended.

5.1.5.2      Production orders

RFR-016580 Correction

Framework: Production
Application: Order maintenance
View: Detail -> Tab “Transport”
Action: Dispatch
Category: Unexpected behavior

Problem: A routing has a cross site operation. In application “Routing”, detail view –> tab “Transport” field “Item(s) for return transport” is changed.
Result: In case a production order uses this routing for dispatching, the value of field “Item(s) for return transport” in the production order detail is not the one defined in routing, but instead the one defined in cross site operation.
This problem may occur with every value which can be set in application “Routing”, detail view –> tab “Transport”.

Correction result: In above described context dispatching uses the values of cross site operation as set in application “Routing”, detail view –> tab “Transport”.

RFR-016580 Correction

Framework: Sales, Production
Application: Sales order maintenance
View: n.a.
Action: Generate production orders…
Category: Unexpected behavior

Problem: When from a sales order production orders are generated following production order quantities must be set:
a) If sales order (detail) quantity is of 1.st item unit, quantity of production order must be the same as of sales order
b) If sales order (detail) quantity is of a inventory managed packaging unit, quantity of production order must be the same as of sales order (that is of inventory managed packaging unit)
c) If sales order (detail) quantity is of a packaging unit which is not inventory managed (“Conversion only”), quantity of production order must be of 1st item unit, converted from sales order from packaging unit
Variant c) does not work anymore since some time.

Correction result: Variant c) does work now as expected.

RFR-016580 Correction

Framework: Production
Application: Order maintenance
View: Dialog: Split or replace operation
Action: Split or replace operation…
Category: Exception

Problem:
1) An external operation of a production order has material provided. The external operation is replaced or split. In the course of reducing quantities of original external operation an exception occurs.
2) An external operation of a production order is completely replaced (no delivery, no reporting). Processing time and/or setup time of master data have unit of measures other than hour. After splitting a subsequent save fails because of an error as unit of measure of target processing time and/or target setup time have been changed to “hour” (which is not allowed anymore).
3) An external operation of a production order is split or replaced by another external operation. New external operation has another supplier and/or another external operation item. The data of the new external operation are not displayed correctly within dialog. Supplier and external operation item from old supplier are displayed in group box “New operation”.

Correction result:
1) Replacing or splitting an external operation with assigned material provided works as expected. No exception occurs. Quantities of original external operation and material provided are reduced properly. For material provided this is done only if “Transfer material” is active.
2) After replacing external operation completely unit of measures of target processing time and target setup time do not change. Saving production order after replacing works as expected.
3) After splitting/replacing a external operation by another external operation (with different supplier and/or external operation item), data in group box “New operation” of dialog are displayed correctly (supplier and/or external operation item of new external operation are displayed).

5.1.6  Purchasing

5.1.6.1      Bonus agreements

RFR-016580 Correction

Framework: Purchasing, sales
Application: Purchasing bonus agreements, Sales bonus agreements
View: n.a.
Action: content change and save
Category: Unexpected behavior

Problem: If the “content language” in the user settings is set to “en”, any changes made to the “Description” field in Purchasing/Sales bonus agreements will not be saved.

Correction result: The problem has been fixed. We can now change and save any changes to the “Description” field if the language in the user settings is set to “en”.

5.1.7  Sales

5.1.7.1      Customer invoices

RFR-016580 Correction

Framework: Sales
Application: Customer invoices
Action: Create
Category: Invalid data / Unexpected behavior

Problem: A utility class that was used for the customer invoice generation has had an error before this correction. As result the attribute “CustomerInvoiceOrderInfos#detailDiscountValues” contains in some cases a wrong value.

Correction result: Now the utility class has been corrected so that the customer invoice attribute contains now the expected data.

5.1.7.2      Sales orders

RFR-016580 Correction

Framework: Sales
Application: Sales orders
View: n.a.
Action: Reserve inventory amount…
Category: Unexpected behavior

Problem: The sales order type reservation setting “Automatically with reservation term” avoided the manual reservation by the reservation dialog.

Correction result: The reservation dialog is using manual reservation settings and will ignore the automatic reservation settings now as expected.

5.1.7.3      Sales quotations

RFR-016580 Correction

Framework: Sales
Application: Customer proposals
Action: Create variant/version based on a draft
Category: Exception

Problem: If a line item of a customer proposal draft is using an item configuration the created variant or version line item does not contain a copy of the item configuration. As result a change of the item configuration within any of such details changes also the other line items. Further this error has the effect that a change within a proposal variant from one line item to an other alternative line item discards the item configuration of the draft line item by mistake.

Correction result: Now the created variant/version line items have – as expected – an own copy of the item configuration data – so these errors do not occur any more.

RFR-016580 Correction

Framework: Sales
Application: Customer proposals
Action: Select and accept items from draft
Category: Exception

Problem: If a variant can be changed manually and a manually added line item is present within the variant an exception occurs durung the tty to execute the action “Select and accept items from draft”.

Correction result: Now the exception does not occur any more.

5.1.8  Solutions Edition

5.1.8.1      Auftragsbezogene Beschaffung

RFR-016580 Correction

Framework: Sales
Application: Sales orders
Action: Save (sub step “Refresh purchase order line items”)
Category: Unexpected behavior

Problems:
1. )
Since “CEE630PB-Fix22 KW17/2025” the “Purchase order line item preferred date” will be changed by some rules with respect to a changed “delivery date”.
But if the “Transition time goods receipt” is used (only in case of “Delivery to issues warehouse”) an unchanged “Purchase order line item preferred date” will not be changed always in analogy to a changed “Purchase order line item delivery date”.
2. )
“Delivery to issues warehouse”: In some cases the “Purchase order line item availability date” is after the “Sales order shipping date”.

Correction results:
1.)
Changed behavior for “Purchase order line item preferred date”:
Precondition: The “Purchase order line item delivery date” changes.
Further conditions: – The “Purchase order line item preferred date” (old preferred date) is the same as the “Old delivery date converted into the preferred date” ==> assert not manually changed.
OR
– The “New purchase order delivery date” is before the “Purchase order line item preferred date” (old preferred date) ==> ensure that the new “Purchase order line item preferred date” is at least the “New purchase order delivery date”
Hint: But if if the “Purchase order line item preferred date” (old preferred date) is before the “New purchase order delivery date” it will stay unchanged.
2.)
Now it will be ensured that the “New purchase order delivery date” plus “Transition time goods receipt” (==>”Purchase order line item availability date”) is not after the “Sales order shipping date” (same date or before this date).
To ensure that the “New purchase order delivery date” will be moved in a loop one working day backwards until this rule is fulfilled.

5.1.9  Storage Location Control

5.1.9.1      Inventory management server

RFR-016580 Correction

Class: com.cisag.app.inventory.location.cache.log. WarehouseCommandLog
Method: throwException(String, int, String…), throwException(String, int, int, String…)

Description: Although the logging is not active the methods both will bind the message text to the CommandException to be created.

5.2     System development

RFR-016578 Correction

Framework: Software development
Application: Job maintainance
Action: activating task plus parallel development
Category: Ergonomics

Problem: If a brand new object is part of a task, the logic searched for a previous version and sends a message.
This could lead to confusion. The transfer works nevertheless.

Correction result: If a object has no previous version then there is now a check in advance whether there should exist a previous version.

RFR-016578 Correction

Framework: System management
Application: Individual indexes
View: n.a.
Action: Generate indexes
Category: Unexpected behavior

Problem: If errors occur during the creation of individual indexes, the application does not display them.

Correction result: The application displays a message indicating that errors occurred during creation. Furthermore, messages are written to the message log.

RFR-016578 Correction

Optimisation of the synchronisation of the shared cache. Acceleration of read processes when several threads access the cache simultaneously.

5.2.1  Application server

5.2.1.1      Autorizations

RFR-016578 Correction

Framework: System management
Tool: wrksec
Category: Unexpected behavior

Problem: After copying a system, an authorization role can contain security definitions for knowledge store objects (documents or folders) using to a workspace which doesn’t belong to the current system or whose database isn’t valid. These are shown as incomplete entries in application Authorization Roles.

Correction result: “wrksec -deleteInvalid” deletes these security definitions.

RFR-016579 Correction

Framework: System management
Tool: wrksec
Category: Unexpected behavior

Problem: After copying a system, an authorization role can contain security definitions for knowledge store objects (documents or folders) using to a workspace which doesn’t belong to the current system or whose database isn’t valid. These are shown as incomplete entries in application Authorization Roles.

Correction result: “wrksec -deleteInvalid” deletes these security definitions.

5.2.2    Workflow

5.2.2.1      Process editor

RFR-016578 Correction

Framework: Workflow
Application: ProcessDefinitions
View: Default
Action: n.a.
Category: Exception

Problem: When three nodes are hovered on top of each other, a NullPointerException occurs.

Correction result: Finitely many nodes can be hovered on top of each other.