Covering Letter Comarch ERP Enterprise 6.4 Delivery CEE640PB-Fix09

Release Comarch ERP Enterprise 6.4
Release date 16.05.2025
Reference to other documents You can find further information in the info texts of the support deliveries for Comarch ERP Enterprise 6.4.

 

This fix comprises the following support deliveries:

RFR-016549 – RFR-016552

 

Information about the features of Comarch ERP Enterprise 6.4 (release news):

·         INF-002734 Release-News: Betriebswirtschaftliche Lösungen

·         INF-002735 Release-News: Technische Lösungen

System requirements:

·         INF-002736 Systemvoraussetzungen Comarch ERP Enterprise 6.4

 

To install the support deliveries, please use the following documentation:

·         “Introduction: Software Logistics” (German language version)

·         „Using Tools and Troubleshooting Help”

To install further languages, use INF-00200 “Sprachaktualisierungen installieren”.

 

The cumulative installation of support deliveries is described in INF-000228.

 

In case of problems during the installation, please refer to INF-000155 “Problembeschreibungen und Vorgehensweisen zur Behebung von Problemen bei der Installation von Supportauslieferungen”.

 

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.

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 CEE640PB-Fix09”.

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 CEE640PB-Fix09

With the delivered software updates, a Comarch ERP Enterprise system that has version CEE640PB-Fix08 will be upgraded to CEE640PB-Fix09.

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 CEE630PB-Fix06 and CEE630PB-Fix13, you can use the manual update procedures described below to upgrade a Comarch ERP Enterprise based system to CEE640PB.

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 CEE630PB-Fix06 is required for the release upgrade. It is not possible to install Comarch ERP Enterprise 6.3 and Comarch ERP Enterprise 6.4 at the same time. Support deliveries for Comarch ERP Enterprise 6.4 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.

4              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.

  • Contained changes and extensions

5.1        Application development

5.1.1    Base

RFR-016551 Correction

Framework: Base
Applications: “Cancellation reasons” and “Cancellation Reason Assignment”
View: n.a.
Action: n.a.
Category: Wrong coding

Problem: The default constructor of the class “com.cisag.app.general.log. CancellationReason(Assignment)Entity” does not have a registered validation; only the copy constructor registers the “CancellationReason(Assignment)Validation”.
So in some cases the entity does not have a validation.

Correction result: Now the coding has been changed in analogy to the template coding of the class “com.cisag.app.general.log.LanguageEntity”.

5.1.1.1      Base – General

RFR-016551 Correction

Frameworks: Purchasing/Sales
Application: “Cockpit: Purchase prices” and “Cockpit: Sales prices”
Action: Display
Category: Invalid data / Unexpected behavior

Problem: The field for the column “Price list level” does not use always the expected value.

Correction result: Now the value is determined as expected.

RFR-016551 Correction

Frameworks: Purchasing and Sales
Applications: Applications with discount fields
Category: Unexpected behavior / Ergonomics

Problem: If the discount unit (percent, currency or “quantity unit”) contains an invalid value this invalid value will be discarded and changed to a percent without any error message (e.g. if a new sales order line item was added to an order).

Correction result: Now an error message will be send as expected.

5.1.1.2      Contracts/RFQs/Quotations/Orders

RFR-016551 Correction

Frameworks: Purchasing/Sales
Applications: “Cockpit: Distribution orders/line items” and “Cockpit: Purchase orders/line items”
Action: Complete delivery (distribution order: source or target)
Category: Invalid data / Unexpected behavior

Problem: In contrast to the “Complete delivery” functionality of the relevant application and the logic used by the sales order line item cockpit the logic used by the purchase and distribution order line item cockpits does not filter the unsupported details.
As result some invalid data will be present that makes problems e.g. in distribution orders that are based of distribution orders.

Correction result: Now also the logic used by the purchase and distribution order line item cockpits filters all unsupported details.
Data update:
If needed you can repair existing wrong distribution order data manually by the help of the normal functionality (example for source delivery completion): – Cancel manual completion of source delivery for distribution order
– Create picking order for delivery order
– Cancel (delete) picking order
– Delete delivery order
– Manually complete the distribution order source delivery

5.1.1.3      Items

RFR-016551 Correction

Framework: Base
Application: Import data
Filter: com. cisag.app.general.obj.Item
Action: Import
Category: Performance

Problem: Item import takes too much time.

Correction result: From now the import will take less time in special cases.

RFR-016551 Correction

Framework: Sales
Application: Sales orders
View: n.a.
Action: n.a.
Category: Ergonomics

Problem: In the item field of the editor the logic, that calculates the (base) item number from a given customer item number, sometimes failed and delivers more than one number. That could happen if the same (customer) item number was used twice for different items and some of these items were marked as deleted already. The marked items were not filtered then and were part of the result.

Correction result: From now items resp. item data, that is marked as deleted will be filtered of the logic as expected and will not be part of the result.

RFR-016551 Correction

Framework: Base
Application: Items
View: Base
Action: n.a.
Category: Unexpected behavior

Problem: An item levy classification could not be assigned to the country based item data if neither ‘Package recycling’ nor ‘Intrastat’ was activated in the customizing application. The tab for the ‘Item country list’ was not be displayed in that case.

Correction result: From now, furthermore, the tab for the ‘Item country list’ will be displayed if ‘Levies’ is activated in the customizing application. That will make it possible to add a levy classification to the country based item data.

5.1.1.4      Partners

RFR-016551 Correction

Framework: Base
Application: Import data
Filter: com. cisag.app.general.obj.Partner
Action: Import
Category: Performance

Problem: Partner import takes too much time.

Correction result: From now the import will take less time in special cases.

5.1.2    Financials

5.1.2.1      Account assignments

RFR-016551 Correction

Framework: Financials
Development object: registry “com. cisag.app.financials.obj.AccountAssignment”
View: n.a.
Action: Data export
Category: Exception

Problem: When the non-standard search account assignments #1#Technical name “com.cisag.app. financials.obj.AccountAssignmentReorganization” is selected in the tab restriction in the application data export and an export is performed for Account assignments, an exception is thrown because the Default search “com.cisag.app.financials.obj.AccountAssignment” has not been entered in Development object registry: “com.cisag.app.financials.obj.AccountAssignment”.

Correction result: The non-standard search is no longer displayed and no exception will be thrown.

5.1.3    Inventory management

5.1.3.1      Availability check

RFR-016551 Correction

Framework: Sales
Applications: Customer proposals and Sales orders
Action: Validate
Category: Invalid data / Unexpected behavior

Problem: In the case that a line item has activated the functionality “Permit multiple inventory owners” the “owner” parameter für the availability inquiry must be ZEROGUID and not the target owner of the line item.
As result the availability inquiry does not work as expected in this case.

Correction result: Now “ZEROGUID” will be if the functionality “Permit multiple inventory owners” is activated for a line item.

5.1.3.2      Availability query

RFR-016551 Correction

Framework: Inventory Management
Application: Reorganize availability and demand data
View: n.a.
Action: Execute batach application “Reorganize availability and demand data”
Category: Unexpected behavior

Problem: If a shipping order was already deleted the reorganization of its availability details caused error messages (shipping order not found) in the job log. The reorganization was already successful but the messages should not be created.

Correction result: The availability details of a deleted shipping order will be marked as deleted in future and they can be reorganized as expected.

5.1.3.3      Delivery orders

RFR-016551 Correction

Framework: Inventory
Application: Delivery orders
View: n.a.
Action: CRUD in tabbed pane “External voucher numbers”
Category: Unexpected behavior

Problem: CRUD actions for external reference numbers did not work correctly if more than one number is changed in the table of the tabbed pane “External voucher numbers”.

Correction result: From now the CRUD actions for external reference numbers will work as expected.

5.1.3.4      Inventory management – General

RFR-016551 Correction

Framework: Update
Application: UPDBUG021670
View: n. a.
Execution of the old data update
Category: Unexpected behavior

Problem: The data update was executed although it should already be executed. It is a data update for the release CEE 6.0. But it is repeatable so it should behave as expected.

Correction result: The data update can be executed as expected although it should not be executed again.
Technical information:
DO NOT execute the already executed Data update that belong to the corrected classes again.

RFR-016551 Correction

Framework: Inventory
Application: Reorganize delivery orders
View: n.a.
Action: n.a.
Category: Ergonomics

Problem: The direct help text of the application was wrong.

Correction result: From now the direct help text of the application will be correct.

5.1.3.5      Inventory postings

RFR-016551 Correction

Framework: Storage Location Control
Application: Inventory orders
View: n.a.
Report a loading unit transport to the shipping zone with automatic partial withdrawal
Category: Unexpected behavior

Problem: The automagical withdrawal could mark the inventory with an error when the inventory on the shipping zone was reserved completely e.g. by the picking order itself.

Correction result: A partial withdrawal from a loading unit or a fill up of a loading at the same place (e.g. direct process on a simple zone) will not change the total quantities as expected. Only the unpacked quantities will be updated and because of that no error is detected anymore.

5.1.3.6      Loading units

RFR-016551 Correction

Framework: Inventory
Application: Loading units
View: n.a.
Action: Create
Category: Unexpected behavior / Ergonomics

Problem: Applying defaults did not work as expected. In special cases creating a loading unit with an added loading unit did not take over the abc-classification of the added loading unit.

Correction result: From now applying defaults will work as expected: The abc-classification will be taken over from an new added loading unit if it’s not set already.

RFR-016551 Correction

Framework: Inventory
Application: Picking orders -> packing dialog
View: n.a.
Action:
Pack
Category: Exception

Problem: When packing with the configuration ‘Pack with loading unit and storage unit’ an exception occurred if the given loading unit is not already persistent.

Correction result: From now packing with the configuration ‘Pack with loading unit and storage unit’ will work as expected. A new loading unit with the given number and SSCC will be created.

RFR-016551 Correction

Framework: Inventory
Application: Loading units
View: n.a.
Action: Reuse loading unit
Category: Exception

Problem: Reusing a loading unit caused an exception if the option “empty loading unit” was activated and former a detail line was loaded to the editor of the maintenance.

Correction result: From now, as expected, if a detail line, that wanted to be loaded in the editor, won’t be available, an error message will be displayed.

RFR-016551 Correction

Framework: Inventory
Application: Loading Units
View: n.a.
Action: Create
Category: Exception

Problem: An exception occurred after creating a new loading unit and then stepping to the view “loading unit structure” after it.

Correction result: From now the application will work as expected.

RFR-016551 Correction

Framework: Inventory
Application: Delivery orders
View: Packing dialog
Action: Pack, Unpack, …
Category: Exception

Problem: An exception occurred if an action was executed for a displayed loading unit that is deleted of another user in the meanwhile since last loading.

Correction result: From now, as expected, an error message will be displayed in that case.

RFR-016551 Correction

Framework: Update
Application: UPDADV103530A
View: n. a.
Action: Execute
Category: Invalid data

Problem: The current unit onhand data for item that are contained in loading units were not correct after the execution of th data update.

Correction result: The current item data will be rebuilt by the data update correctly as expected.

Data update: It is not necessary to execute the data update again. If there are those problems the hidden update application “Recompile shadow inventories” (com.cisag.app.inventory.tools.ui. RefreshCurrentStocks) could be used to correct the current data of the concerned warehouse.

5.1.3.7      Picking orders

RFR-016551 Correction

Framework: Sales / Inventory
Application: Sales orders
View: n.a.
Action: Generate picking order
Category: Exception

Problem: An exception occurred creating a picking order for a sales order. This happens if the sales organization of the sales order is not an inventory organization and empties line items will be created in the delivery process.

Correction result: From now creating a picking order for a sales order will work as expected.

RFR-016551 Correction

Framework: Inventory
Application: Inventory orders, picking orders, delivery orders
View: n.a.
Action: Save and Report
Category: Invalid data

Problem: In special cases the usage status of loading units, reported by an inventory order to a picking order or delivery order, was not valid after reporting.

Correction result: From now the usage status will be “Issue of goods” as expected.

5.1.3.8      Reservations

RFR-016551 Correction

Framework: Inventory Management
Application: Reservations
View: n.a.
Execution of actions that based upon data that was changed in the meantime
Category: Exception

Problem: If a demand (origin or coverage) was selected to be updated for a reservation action an exception could be caused if the database object was deleted by another process or user.

Correction result: The actions were extended to be safer against concurrent changes. Often there will be a message that informs the user about changed data as expected.

5.1.4    Multi-site capability

5.1.4.1      Inter-company billing

RFR-016551 Correction

Framework: Base
Application: Inter-company billing
Action: Create “Inter-company billing”
Category: Exception Unexpected behavior

Problem: By the customer invoice type the functionality “Clear billing line item internally” can be activated. If so the “Inter-company billing” generation tries to refresh the status of the original sales order detail (with quantity zero) because within the internal billing data as “order” the original sales order detail is used. If this detail is canceled an exception occurs; if it is not canceled it works as expected randomly. For the sales order detail such an “Inter-company billing” is not relevant for the internal billing status – so the “Inter-company billing” generation must not refresh the sales order detail status (also if not canceled).

Correction result: Now the “Inter-company billing” generation does not refresh the sales order detail if the original sales order detail has the total quantity zero.
In analogy also no status update will be performed if the original order detail is a purchase order detail with the total quantity zero.

Hint: Can currently not occur because in purchasing the invoice header will be used as “order” within the internal billing data.

RFR-016551 Correction

Frameworks: Base, Sales
Applications: “Inter-company billing”, “Customer invoices”
Actions: “Generate inter-company billing”, “Cancel inter-company billing”
Category: Exception / Invalid data / Unexpected behavior

Problem: At least since the year 2007 the customer invoice line item attribute “deliveryOrganization” is filled by the “Inter-company billing” logic with the wrong value (“InventoryTransaction:sourceOwner”).
Because of a change within “CEE640PB-Fix04 KW42/2024” that uses this wrong value an exception can occur e.g. during the cancellation of such an “Inter-company billing” if the “sourceOwner” is not an inventory organization – also the wrong inventory item data might be used.

Correction result:
1. The “Inter-company billing” logic uses now as “deliveryOrganization” the site of the storage area – as result the customer invoice data is now as expected.
If the “Inter-company billing” data contains no storage area the “deliveryOrganization” will be tried to set by the posting order data.
2. The customer invoice cancellation uses now the site of the storage area (as before if present only) to determine the inventory item data – so there is no need to correct the wrong customer invoices by a data update application.

RFR-016551 Correction

Framework: Base
Application: Inter-company billing
Action: Create summary invoice
Category: Invalid data / Unexpected behavior

Problem: If a “Inter-company billing” is created as “summary invoice” the customer invoice line item “cost of goods” value was not determined as expected (with the wrong quantity).

Correction result: Now the “cost of goods” value will be determined as expected.
Data update:
If needed you can cancel the wrong Inter-company billing invoices and recreate them with the corrected coding.

5.1.5    Planning

RFR-016551 Extension

Framework: Planning
Application: Material requirements planning
View: n.a.
Action: all planning actions
Category: New feature

Description: The planning log file tracks messages in the order they occur during the planning run.
In case identical messages occur, they have been written multiple times to the file.
Now duplicate messages are recognized and not written into the planning log a 2nd time
as long as they are found within the last 10000 messages written.

5.1.6    Production

RFR-016551 Correction

Framework: Production
Application: Production issues
View: n.a.
Action: Post production issues
Category: Unexpected behavior

Problem: When posting a production issue, an error message is triggered rarely, seemingly under random conditions.
The error message is “Data have been changed by user ‘yourself'”, and the production issue posting fails.
The production order is not correctly locked as well.
The same problem appears when adding identifier lines, saving and then posting a production issue.

Correction result: No error message occurs, production issue can correctly be posted, production order is correctly locked.

RFR-016551 Correction

Framework: Production
Application: Receipt of goods, Operation postings
View: n.a.
Action: Post
Category: Unexpected behavior

Problem: A material of a production order has a setup quantity. Quantity (target + setup) is reported automatically.
Note: in application “production orders” setup quantity is not displayed only sum of target and setup.
A receipt of goods is done which only covers part of target quantity of production order.
Result: material is reported automatically. Reported quantity is the prorated value of target + setup.

Correction result: Automatic reporting of material with setup quantity must be done as follows.
First (partial) receipt of goods must trigger a report of material with complete setup quantity + prorated value of genuine target quantity.
Following (partial) receipt of goods must trigger a report of material with prorated value of genuine target quantity only.
Example: Target quantity production order: 1000, target quantity material: 1000, setup quantity material: 100
First receipt of goods: 300 –> reported quantiy of material is 100 + 300 = 400
Second receipt of goods: 700 –> reported quantity of material: 700
Cancellations of receipt of goods: Only if the (last) receipt of goods sets back reported quantity to zero the complete setup quantity + prorated value of genuine target quantity of material is canceled.
Example from above continued: Receipt of goods of 300 canceled –> reported quantity of material is -300.
Receipt of goods of 700 canceled –> reported quantiy of material is -100 + -700 = -800!
Please note: New automatic reporting behaviour with specified fixed quantity works also when automatic report is triggered by operation posting.
Additional: System porperty com.cisag. app.production.ui.MaterialIssuePostingList_displayFixedQuantity=true enables displaying column “of which setup quantity” right of column “Total quantity” of application “Production issues”. Column displays the part of “Total quantity” which counts for setup quantity.

RFR-016551 Correction

Framework: Production
Application: UPDADV116308
View: n.a.
Action: n.a.
Category: Invalid data

Problem: A parallel data update could write to the BO ResourceAvailability. This could lead to inconsistencies in the migrated data.

Correction result: Parallel writes are prevented by the general Resource locking mechanism.

5.1.6.1      Product configuration

RFR-016551 Correction

Framework: Production
Application: Product configuration rules
View: a) “Configuration characteristics” and b) “Conditions and actions”
Action: a) right click on field “Step” and choose “Properties”, b) right click on field “Condifiton list”/”Start condition list” and choose “Properties”
Category: Exception

Problem: Performing actions described above in views a) “Configuration characteristics” or b) “Conditions and actions” causes an exception.

Correction result: Performing actions described above in views a) “Configuration characteristics” or b) “Conditions and actions” work as expected. No exceptions occur.

5.1.6.2      Production orders

RFR-016551 Correction

Framework: Production
Application: Cockpit: Production orders
View: n.a.
Action: Change due date and quantity…
Category: Unexpected behavior

Problem: If more than one order selected in Cockpit: Production orders are rescheduled, this action may fail for all or some orders.
Rescheduling fails for those orders which have a target quantity of inventory managed packaging unit. A error message is output which states that unit of measure of rescheduling quantity does not match unit of measure of target quantity of production order (PRD-02453)

Correction result: Rescheduling of more than one production order selected in Cockpit: Production orders is performed as expected. No error messages are output.

5.1.7    Purchasing

5.1.7.1      Puchasing – General

RFR-016551 Correction

Framework: System Management
Application: UPDADV088978
Action: Execute
Category: Exception

Problem: The update application “UPDADV088978” of the release 6.1 initializes some new attributes by some old attributes. In the same step some of these old attributes were set in the year 2018 to deprecated.
Within “CEE640PA KW52/2023” the deprecated attributes were deleted. So “UPDADV088978” cannot be executed any more.

Correction result: The update application “UPDADV088978” was deleted.

RFR-016551 Correction

Framework: Purchasing
Applications: “Assign supplier invoices” and “Assign receipts of goods”
Action: Sort order
Category: Unexpected behavior / Ergonomics

Problem: The sort order as stored within the “Standard” layout of these applications was not well defined.

Correction result: Now the sort order is definedso:
1. “Assign supplier invoices”: Receipt date (descending); all further attributes ascending: receipt line item (type code, header number, main and sub line item number), purchasse order line item (type code, header number, main and sub line item number)
2. “Assign receipts of goods”: Invoice date (descending); all further attributes ascending: invoice line item (type code, header number, main and sub line item number), purchasse order line item (type code, header number, main and sub line item number)

5.1.7.2      Purchase order confirmations

RFR-016551 Correction

Framework: Purchasing
Applications: “Cockpit: Purchase order confirmations” and “Cockpit: Purchase order confirmations/line items”
Category: Unexpected behavior / Ergonomics

Problem: The field “Confirmation number” does not have a value assistant.

Correction result: Now the field has the expected value assistant.

5.1.7.3      Supplier invoices

RFR-016551 Correction

Framework: Purchasing
Application: Supplier invoices
Action: Generate correction supplier invoice
Category: Exception

Problem: If the purchasing organization of a supplier invoice and the purchasing organization of an assigned purchase order are different and have different domestic amount combinations an exception occurs during the try to perform the “Generate correction supplier invoice” logic.

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

RFR-016551 Correction

Framework: Purchasing
Application: Supplier invoices
Action: Change view
Category: Unexpected behavior / Ergonomics

Problem: If the view is changed manually by the line item data will not be cleared (in contrast for example to the receipt maintenance).

Correction result: Now the data will be cleared as expected.

5.1.8    Sales

5.1.8.1      Customer invoices

RFR-016551 Correction

Framework: Sales
Application: “Customer invoices”
Actions: “Cancel”
Category: Exception

Problem: In some cases, an exception occurs during the try to cancel a customer invoice.

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

RFR-016551 Correction

Framework: Sales
Application: Customer invoices
Action: Generate customer invoice
Category: Exception / Invalid data / Unexpected behavior
Problems: Multiple problems in case of retail calculation and the kind of pricing value “Gross” in the case that discounts with own accounts are used.
1) Because of the correction delivered by “CEE630PB-Fix19 KW45/2024” a new NullPointerException can occur within the method “com.cisag.app.sales. invoice.log.DefaultUpdate.calculateValuesWithoutTax”.
2. A “java.lang.IllegalArgumentException: details must not be empty!” can occur within the method “com.cisag.app.sales.invoice.log.InvoicingEntity. dispatchRoundingDifferences”.

Correction result: Now both problems have been corrected.

5.1.8.2      Sales – General

RFR-016551 Correction

Framework: Sales
Applications: “Order confirmations query” and “Pro forma invoices query”
Action: Generate
Category: Invalid data / Unexpected behavior

Problem: In the “Net” price display, the header discount values of the line items are by mistake the double of the correct value.

Correction result: Now the header discount values have the expected values.

Hint: Please note that in contrast to the “Net” price display of customer invoices the discount values are not cleared (as before).

RFR-016551 Ergonomics

Framework: Sales
Application: “Order confirmations query”, “Pro forma invoices query”, “Customer invoices query”
Action: “Complete and output … ”
Category: Ergonomics

Problem: Within these three applications the “Complete and output …” action is currently only used in case of levies and levies are still under construction.
In future these actions might be used also for a document preview.

Correction result: To avoid some confusion about this action it will be present now only if levies are available for the current system.

Hint: At the moment only in internal test systems.

5.1.8.3      Sales cockpit

RFR-016551 Correction

Framework: Sales
Application: Cockpit: Sales Orders
View: n.a.
Action: “Generate order confirmations” and “Generate and output pro forma invoices”
Category: Exception

Problem: If multiple orders are selected within the “Cockpit: Sales Orders” for the actions “Generate order confirmations” or “Generate and output pro forma invoices” a “java.lang.RuntimeException: Get of object not possible: transaction not found” occurs up from the support delivery “CEE640PB-Fix02 KW30/2024”.

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

5.1.8.4      Sales orders

RFR-016551 Correction

Framework: Sales
Applications: “Customer proposals” and “Sales orders”
Action: Recalculate
Category: Exception

Problem: If a customer proposal or sales order calculates tax data and uses freight costs or empties an exception can occur during the try to recalculate the order.

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

Hint: In addition to that a wrong condition for “relevant header change” have been correct within the “document freight cost logic”.

5.1.8.5      Simulate sales prices

RFR-016551 Extension

Framework: Sales
Application: “Simulate sales prices” and “Price origin dialog” of sales documents
Action: Display calculation data
Category: Ergonomics

Description:
1.
In the “Net” price display the consideration of discounts is started with a price and changes during the calculation to a value. Before this extension it was difficult to detect such a change from “price to value”.
==> Up from now such a change will be displayed as new row that contains the value that is used for the further calculations.
2.
In the “Net” price display the last step will calculate a rounded net price and calculates a rounded net value that is based on this rounded net price. Before this extension the temporary net value (after consideration of all discounts) was not displayed – so if needed it has to be calculated manually by the user.
==> Up from now a “sub total” line will be displayed always with the value that is used as base for the rounded net price.

5.1.9    Storage Location Control

5.1.9.1      Inventory requisitions

RFR-016551 Correction

Framework: Inventory Managment
Application: Inventory Requisitions
View: n.a.
Create new line item with a picking storage location
Category: Unexpected behavior

Problem: If a picking location was specified without a slot but its item definition contains a slot the validation would fail although this constellation is allowed by the automatic slot assignment.

Correction result: If the automatic slot assignment supports the specified picking location without slot specification the line item can be overtaken as expected.

5.1.9.2      Storage location reservations

RFR-016551 Correction

Framework: Inventory Management
Application: Receipt of goods
View: n.a.
Action: Cancel receipt of goods…
Category: Unexpected behavior

Problem: A receipt of goods could not be cancelled if the inventory order of the original receipt of goods was completed with “Discard open put-away” and the receipt of goods contains serial numbers.

Correction result: Although serial numbers are contained a receipt of goods can be cancelled as expected.

5.2        Apps

5.2.1    Rental

RFR-016551 Extension

Class:
– com.cisag.app.general.partner.model. Customer
– com.cisag.app.general.partner.model.Supplier
– com.cisag.app.general.partner.model. PartnerFinancialsData
– com.cisag.app.general.partner.model.MarketingInfo
Method: several “retrieve”-methods were added

Description: ‘retrieve’ methods were made available in these object views to enable access to the (possibly) parallel changed data of the other partner views in the actual editing context.

Class:
– com.cisag.app.general.item.model.SalesItem
– com.cisag.app. general.item.model.PurchaseItem
– com.cisag.app.general.item.model.InventoryItem
– com.cisag.app. general.item.model.ProductionItem
– com.cisag.app.general.item.model.ItemPlanningData
– com.cisag. app.general.item.model.ItemAccountingData
Method: several “retrieve”-methods were added

Description: ‘retrieve’ methods were made available in these object views to enable access to the (possibly) parallel changed data of the other item views in the actual editing context.

5.3        System development

RFR-016549 Correction

Framework: All
Action: copying NLS Data
Category:Unexpected behavior

Problem: If a two transient instance of business object both containing supplement are copied into each other and the supplement has an NLS attribute,
then it can happen that a previously set value for a secondary language is lost on copy.

Correction result: the copy process now works as expected for NLSData of a supplement.
Technical information: NLSData are only loaded if needed. In order to know what to load a key is copied.

RFR-016549 Correction

Changed the implementation to the Bill Pugh Singleton pattern.

RFR-016549 Correction

Framework: System Management
Application: Software updates cockpit
View: Imported Software updates
Action: Install.
Category: Unexpected behavior

Problem: If an installation was started within the software update cockpit and only language refreshes are installed,
then the end trigger for the installation was not reached.
This kept the installation open. This lead to problems for the next regular installation.

Correction result: When using the ‘Install’ action the installation is now correctly marked as finished in the end.

5.3.1    Data exchange

RFR-016549 Correction

Framework: System Management
Web service calls (incoming)
Category: Unexpected behavior

Problem: Multiple web service calls that re-use the CEE session, and use URL query strings “contentLanguage” or “displayLanguage” with different languages specified for the query strings among subsequent calls, may fail with a HTTP 500 status code, and ”

Correction result: The problem is resolved.

Technical information: The problem occurs in the third call with a different language specified for one of the query strings, and the calls are actually executed in the same session.

5.3.2    GUI

5.3.2.1      Client (browser)

RFR-016549 Correction

Recognition of the client’s touch capability has been improved. Now it is not based on the user agent, but on the recognition of the touch event handler.

5.3.3    Kernel

RFR-016549 Correction

Framework: System management
Application: Change journal query
View: Business entity
Action: Update
Category: Exception

Problem: The modification journal data might be inconsistent, e.g. if they were copied from another system with a different repository database. The referenced table descriptions might not exist in the current repository. This results in exception “IllegalArgumentException: Parameter o1 must not be null.”
Correction result: Error message KRN-1391 is updated to cover undefined table descriptions.

RFR-016550 Correction

Framework: System management
Application: Change journal query
View: Business entity
Action: Update
Category: Exception

Problem: The modification journal data might be inconsistent, e.g. if they were copied from another system with a different repository database. The referenced table descriptions might not exist in the current repository. This results in exception “IllegalArgumentException: Parameter o1 must not be null.”
Correction result: Error message KRN-1391 is updated to cover undefined table descriptions.

5.3.3.1      Locking / Caching

RFR-016549 Correction

Process: Locking
Category: Exception

Problem: A NullPointerException (at com.cisag.sys.kernel.locking.CisLockTable.removeLockEntryByRequester) might occur randomly, if two or more requesters are waiting to acquire the same lock and a timeout occurs.

Correction result: Fixed.

War dieser Artikel hilfreich?