| Release | Comarch ERP Enterprise 6.3 |
| Release date | 28.03.2023 |
| Reference to other documents | You can find further information in the info texts of the support deliveries for Comarch ERP Enterprise 6.3.
This fix comprises the following support deliveries: RFR-016483 – RFR-016485
Information about the features of Comarch ERP Enterprise 6.3 (release news): · INF- 002654 Release-News: Betriebswirtschaftliche Lösungen · INF-002656 Release News: Business Solutions · INF- 002655 Release-News: Technische Lösungen · INF-002661 Release-News: Technical Solutions
System requirements: · INF-002659 Systemvoraussetzungen Comarch ERP Enterprise 6.3 · INF-002660 System Requirements Comarch ERP Enterprise 6.3
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.
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-Fix14.”
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 to the message server or to 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-Fix14
With the delivered software updates, a Comarch ERP Enterprise system that has version CEE630PB-Fix13 will be upgraded to CEE630PB-Fix14.
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 is 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 Supportauslieferungen” which contains information about possible causes and about instructions on how to solve the problem.
4.1 Data updates
No data updates have to be carried out.
4.2 Batch data updates
With the “Query data updates” application, you must schedule the following data updates, for any point in time.
4.2.1 UPDSUP113815
The data conversion of the supplierOrigin field is as follows: Supplier without value and supplierOrigin = null => SupplierOrigin -> 1 = No supplier Supplier with value and supplierOrigin = null => SupplierOrigin -> 5 = Manually defined supplier.
5 Contained changes and extensions
5.1 Application development
RFR-016485 Documentation
“What’s this” help of application “Reorganize picking orders” has been corrected.
RFR-016485 Ergonomics
German UI texts have been corrected.
RFR-016485 Correction
Framework: System-Management
Application: Import data
View: n.a.
Action: Import Items
Category: Unexpected behavior
Problem: Importing “other fields” of type classification with organization for the business entity Item does not work. For example, “Inventory item classification 1”. If an import tries to change the value of such a field, the old value will be deleted and no new value will be set.
Correction result: Importing “other fields” of type classification with organization works without restrictions.
RFR-016485 Correction
Framework: Base
Application: Partner
View:
Action: Other Fields -> New
Category: Unexpected behavior
Problem: Default value of URL field is not validated when creating the field.
Correction result: Default value of URL is validated now.
RFR-016485 Correction
Framework: Production
Application: com.cisag.app.production.prodconf.ui.ConfigurationRuleMaintenance
View: n.a.
Action: Cancel on setting restrictions
Category: Unexpected behavior / Ergonomics
Problem: Open TRPA-TEST, set the View to “4 Conditions and Actions”, select 10-40, in the Editor get the dialog to edit the Restriction, there open the Popup, add any value e.g. “100 Tassen”, “Ok”, then cancel. The field Restrictions does not have “100 Tassen” added. So far so correct. Then open the dialog again. The “100 Tassen” is now still in there and as if it had been confirmed also in the field.
Correction result: Any change is lost upon canceling the dialog.
RFR-016485 Documentation
The new help documents “Erklärungen importieren” and “Verarbeitungszwecke importieren” have been updated according to programmer hints.
5.1.1 Base
5.1.1.1 Base – General
RFR-016485 Correction
Framework: General
Application: Item characteristics
View: n.a.
Action: n.a.
Category: Unexpected behavior
Problem: Values of type long text, coming from dynamic fields, were incorrectly compared internally. This resulted in faulty behavior were two long texts were compared against each other.
For example, the application “Item characteristics” detects changes in long texts, even when there were no changes.
Correction result: Long texts, coming from dynamic fields, are now properly compared against each other.
5.1.1.2 Contracts/RFQs/Quotations/Orders
RFR-016485 Documentation
Class: com.cisag.app.general.order.log.Entity
Methods: “public void save()” and “public void delete()”
Description: The pattern of the order APIs requires that after the call of the methods “save” and “delete” the result of “requires attention” needs to be used and if true the transaction must not be committed.
In addition to that a reference to the class “com.cisag.app.general.order.log.EntityUtility” has been added to both methods.
The signatures of the method “EntityUtility#mainSaveAndReload” implement the correct pattern for the “save case”.
The signatures of the method “EntityUtility#delete” implement the correct pattern for the “delete case”.
In many cases the EntityUtility methods can be used directly and so ensure a correct usage.
5.1.1.3 Due date types
RFR-016485 Correction
Framework: Base
Application: Partners
View: Customers
Action: n.a
Category: Unexpected behavior
Problem: The left part of the compound field “Due date type” was not displayed any more.
Correction result: From nowon, the left part of the compound field “Due date type” will be displayed as expected.
5.1.1.4 Item characteristics
RFR-016485 Correction
Framework: Base
Application: Item characteristic classifications
Action: Duplicate in nodes at the same level
Category: Exception. Invalid data / Unexpected behavior
Problem:
1. Up from the release 6.3 the action “Duplicate in nodes at the same level” does not copy the current data to new data – instead the source data will be used also as target data.
2. In addition to that, an exception occurs during the try to duplicate a node with children.
Correction result: Now the action works again as expected.
5.1.1.5 Partners
RFR-016485 Correction
Class: com.cisag.app.general.obj. PartnerRelationImpl
Method: get_instanceString()
Description: The method caused a NullPointerException. From now a NullPointerException will not occur in that method any more.
RFR-016485 Correction
Class: com.cisag.app.general.log. AddressDataDataObject
Method: retrieveCountryRegion()
Description: The method caused an NPE if no region is defined for the address. From now the method will return NULL in that case.
5.1.1.6 Voucher document templates
RFR-016485 Correction
Framework: Base
Application: Voucher document templates
View: n.a.
Action: Save, Validate
Category: Exception
Problem: java.lang. IllegalArgumentException will be thrown if the input on the field “Business object” was not an Business object.
Correction result: No Exception occurs anymore.
5.1.2 Calculation
5.1.2.1 Calculation schemas
RFR-016485 Correction
Framework: Calculation
Application: Calculation schemas
View: n.a
Action: n.a.
Category: Unexpected behavior
Problem: In some cases the valueset-field supplierOrigin contains the value null both if the supplier is without value and with value.
Correction result:
Data update: The application UPDSUP113815 must be called up in the menu Data updates query
Data conversion of the field supplierOrigin contents as follows: supplier without value and supplierOrigin = null => SupplierOrigin -> 1 = No supplier
supplier with value and supplierOrigin = null => SupplierOrigin -> 5 = Manually defined supplier.
5.1.3 Compliance management
RFR-016485 Correction
Framework: Compliance Management
Application: Processing purposes
Action: Data import
Category: Unexpected behavior / Ergonomics
Problems:
1. The export and import filter of the business object “com.cisag.app.compliance.obj.ProcessingPurpose” contains the internal attribute “text”.
2. The import filter of the business object “com.cisag.app. compliance.obj.ProcessingPurpose” contains the attributes “managingSystem” and “updateInfo” – both attributes are maintained by the system engine and are not supported by the import.
Correction result: The export and import filter have been corrected.
5.1.4 Inventory management
5.1.4.1 Delivery orders
RFR-016485 Correction
Framework: Sales / Purchasing
Application: Purchase orders
View:
Action: Generate delivery orders for external deliveries…
Category: Exception
Problem: Generating delivery orders for external deliveries an exception occurred. That happened if the purchase order contained a canceled detail line, where the corresponding sales order detail line is already deleted.
Correction result: From now generating delivery orders for external deliveries will work as expected.
5.1.4.2 Inventory count
RFR-016485 Correction
Framework: Inventory Management
Application: Inventory counts
View: n.a.
Action: Generate inventory differences lists…
Category: Unexpected behavior
Problem: The generation of inventory differences lists did not consider the inventory owner of the inventory count. That could cause an unnecessary amount of line items.
Correction result: The generation of inventory differences lists will only consider the inventory owner of the inventory count as expected.
RFR-016485 Correction
Framework: Inventory management
Application: Inventory counts
View: n.a.
1. Generate item based count lists
2. Close inventory count list line item
Category: Unexpected behavior
Problem:
1. Although the inventory count type was not for equipment item-based count lists could contain them.
2. If a line item is only closed and not the whole count list the closing date values were not correctly set.
Correction result:
1. Only inventory counts for equipment will contain equipment as expected.
2. If a line item is only closed and not the whole count list the closing date values will be set for today as expected.
5.1.4.3 Inventory management – General
RFR-016485 Correction
Framework: Inventory
Application: Delivery orders / packing dialog
View: n.a.
Action: Pack (into loading unit)
Category: Invalid data
Problem: It was possible to get invalid data when packing a delivery order to loading units in case of having a dead lock reading reservation data. The reason for it was an error in error handling of the transaction of the packaging logic.
Correction result: From now the error handling will work as expected. No invalid data will be created in an error case.
5.1.4.4 Inventory postings
RFR-016485 Correction
Framework: Production
Application: Inventory posting
View: Inventory posting
Action: Validate
Category: Exception
Problem: When inventory posting field “Special process” was set to “Material provided to vendor” and field “Production order line item” was set to line item of type “external production operation”, an exception occurred and the application crashed.
Correction result: An error is now sent instead of an exception and the application does not crash anymore.
5.1.4.5 Loading units
RFR-016485 Correction
Framework: Inventory
Application: Goods receipts (Packing dialog)
View:
Action: Create loading units …
Category: Unexpected behavior / Ergonomics
Problem: Calculating defaults, taken from item data, did not work as expected for a created loading unit if serial number items were packed.
Correction result: From now calculating defaults will work as expected.
5.1.4.6 Picking orders
RFR-016485 Correction
Framework: Inventory
Application: Picking orders
View: n.a.
Action: Complete picking order
Category: Exception
Problem: An exception occurred completing a picking order for an identifier managed detail line. That happened in the special case when quantities via transport order were reported and reset to zero after it.
Correction result: From now completing a picking order will work as expected.
RFR-016485 Correction
Framework: Inventory
Application: Production orders
View: n.a.
Action: Create picking slip
Category: Exception
Problem: An exception occurred creating a picking slip from a production order if the function ‘Identifiers’ is deactivated in the ‘Customizing’ application.
Correction result: From now creating a picking slip from a production order will work as expected.
5.1.4.7 Receipts of goods
RFR-016485 Correction
Framework: Inventory
Application: Goods receipts
View: Distribution
Action: Load
Category: Exception
Problem: Loading a cancel goods receipt threw an exception if the canceled goods receipt was already reorganized.
Correction result: From now loading a cancel goods receipt will work as expected even if the canceled goods receipt was already reorganized.
RFR-016485 Correction
Framework: Inventory
Application: Goods receipts
View: n.a.
Action: Cancel goods receipt partially …
Category: Ergonomics
Problem: Some fields in the ‘Cancel partially’ dialog displayed invalid values and the displayed order of transport order detail lines did not fit for sub detail lines.
Correction result: From now the displayed values and the displayed order of the transport order detail lines will be as expected.
5.1.4.8 Reservations
RFR-016485 Correction
Framework: Inventory Managment
Application: Production orders
View: n.a.
Action: Change a line item from an item-based line item to a concrete identifier-based line item
Category: Exception
Problem: If the specified identifier is completely available within the production warehouse the demand data for the outgoing warehouse was tried to be created with a zero demand. This caused an exception.
Correction result: It is now possible to create a new zero demand as expected. This means it will be completed suddenly after its creation.
RFR-016485 Correction
Framework: Inventory managment
Application: Automatic reservation (Background)
View: n.a.
Action: Execute
Category: Unexpected behavior
Problem: If different parallel processes need the same warehouse stock context (e.g. reservations or secured stock proposals) they will be concurrent.
Correction result: Within the background application “Automatic reservation” the behavior is changed (lower wait time and single processing). Because of that the time of waiting for data base locks will be reduced and this reduces the possibility of time out exceptions.
RFR-016485 Correction
Class: com.cisag.app.inventory.reservation.log. FixedReservationAvailabilityMaintenanceLogic
Method: Data.changeStatus(DataEntry)
Description: The value of the unit obligation will now be overtaken from the availability detail the specified data entry belongs to.
RFR-016485 Correction
Framework: Inventory management
Application: Purchase orders, Production orders
View: n.a.
Change of the incoming inventory packaging unit
Category: Unexpected behavior
Problem: If the incoming quantities were changed to an inventory packaging quantity (unit obligation is considered) the reservation could be lost although it was a compatible change. A compatible change could be that the new incoming packaging contains the previous packaging and the quantity is sufficient.
Correction result: The compatible change to an inventory packaging will not remove the currently existing reservations as expected. Incompatible changes will still remove the reservations maybe they will be automatically reserved by other automatic reservations settings.
5.1.5 Multi-site capability
5.1.5.1 Inter-company billing
RFR-016485 Correction
Framework: Base
Application: Inter-company billing
Action: Generate inter-company billing
Category: Exception
Problem: If for an “internal billing data” entry no price listing can be determined an exception occurs by the execution of the action “Generate inter-company billing”.
Correction result: Now such an entry will be skipped so that the exception does not occur any more.
5.1.6 Planning
RFR-016485 Correction
Framework: Planning
Application: Material Requirements Query
View: daily
Action: n.a.
Category: Unexpected behavior
Problem: In case an item was configured with a planning time fence in planning view, the forecast was not transferred into planning memory as stated in documentation:
1. The end of the planning time fence was calculated as calendar days, not as working days.
2. Only purely day-based forecasts started exactly at the day after the time fence. When daily data was generated for week or monthly forecasts via even distribution it could happen that forecasts were delivered into following logic parts that did not expect forecasts before the time fence end, thus leading to wrong planning results and wrong display.
3. In case the planning option “Prior period’s forecast results” was configured to “Issues only” the planning result was correct, but the forecasts were displayed wrong in application “Material Requirements Query”
Correction result:
1. The end of the planning time fence is now calculated as working days after the planning start.
2. No forecasts before the planning time fence are loaded into planning.
3. Pre-period forecasts are not displayed as demand in “Material Requirements Query” in case “Prior period’s forecast results” is configured to “Issues only”.
RFR-016485 Correction
Framework: Production
Application: Material requirements planning
View: n.a.
Action: Transfer planning data and execute planning, Update planning data and execute planning
Category: Invalid data
Problem: If errors PRD-01101 or PRD-01102 occurred during planning, these errors displayed incorrect information that the start/end of the operation was more than 5 years in the past/future, even though the number of years depends on the system property and it is not constant number five.
Correction result: Now those two error messages shows proper number of years which are equal to system property.
Technical information: The number of years is taken from system property: com.cisag.app.production.scheduling.log. ResourceLogicImpl_SchedulingTimeHorizon.
5.1.6.1 Material requirements planning
RFR-016485 Correction
Framework: Planning
Application: Material requirements planning
View: n.a.
Action: all planning actions
Category: Unexpected behavior
Problem:
1. In case forecasts and delivered orders are present within the same forecast period, the delivered order quantity should count like a demand, but it was not considered during the planning phase.
2. When forecasts are not considered in pre-period, they must still be accumulated in pre-period to start from a non-zero value at the first planning day.
3. When planning was updated an object id mismapping could occur in rare cases. This could lead to data being ignored in planning memory.
Correction result:
1. The delivered orders the forecast period is considered as additional demands. This means that the accumulated demands are increased accordingly.
A recommendation based on forecasts can only happen in case the accumulated forecasts of the forecast period are higher than the demands.
This means when delivered order are present, the forecasts will exceed the demands on a later day than without considering the delivered orders as demands.
Thus, when delivered order are properly considered as demand, the day of the first recommendation due to forecasts will be on a later day, the first day at which accumulated forecasts are higher than accumulated demands.
2. The modes considering / not considering forecasts in pre-period both accumulate forecasts in pre-period. In case the forecasts shall not be considered to be counted as demands, the accumulated forecast amount is cropped down to the real demands before the first planning day, so it does not exceed the real demands at the first planning day.
3. The internal id-mapping of planning data objects has been completely rewritten to ensure an ID is only given out once, so it is unique.
RFR-016485 Correction
Framework: Production
Application: Material requirements planning
View: n.a.
Action: Transfer planning data and execute planning
Category: Exception
Problem: In application “Material requirement planning” when perform planning with checkbox “Use delivery calendar” checked there was an exception if used database was of type DB2.
Correction result: Now there is no exception in that case when using database of type DB2.
RFR-016485 Correction
Framework: Planning
Application: Material requirements planning
View: n.a.
Action: “Transfer planning data and execute planning”, “Update planning data and execute planning”
Category: Unexpected behavior
Problem: Sales order details of type branch order (see sales order type) were not regarded by planning so far as it was assumed that demand and receipt quantity cancel each other.
Target warehouse of sales order detail of type branch order must be a warehouse without reservation. But corresponding issue warehouse can be a warehouse with reservation.
If this is the case receipt quantity of branch order detail is neglected whereas demand quantity of branch order type indirectly is regarded (starting inventory is reduced by reserved quantities).
This leads to recommendations if “pure” demands exist.
It is assumed that planning regards above mentioned issue warehouse as well as target warehouse.
Correction result: In above described context the receipt quantity of a sales order detail of type branch order is regarded in planning (as well as demand quantity of this sales order detail).
No unexpected recommendations for “pure” demands are generated.
RFR-016485 Correction
Framework: Planning
Application: Material requirements planning
View: n.a.
Action: Update and plan
Category: Exception
Problem: There was an exception thrown during planning at the point when the APSItemPlanningResult objects are stored: java. lang.RuntimeException: Key is invalid as some key fields are invalid!
The problem appears rarely, is not reproduceable and seems to be caused by the update mechanism of the planning.
Correction result: The missing key information is detected and PRD-01123 is created. Results from unaffected items are stored.
Technical information: The root cause is addressed in BUG-028562.
5.1.7 Production
RFR-016485 Correction
Framework: Production
Application: Sales order/Production order maintenance
View: n.a.
Action: Sales order maintenance: Generate production order
Category: Unexpected behavior
Problem: A sales order details unit of measure (uom) is an inventory managed packaging unit. The packaging unit is binding. If for this sales order detail a production order is generated the quantity of production order is in base unit of measure of product/sales item. If reservation is active production order cannot be reserved for sales order detail as unit of measures deviate.
Correction result: If in above described context a production order is generated from sales order detail the target quantity of production order is of packaging unit of sales order detail. Reservation for sales order detail is complete and refers to generated production order. Reservation stays complete after receipt of goods of production order (changes to reservation against inventory). If receipt of goods is partial, reservation of sales order detail is reserved against inventory as well as against production order (for not reported quantity).
If a production order is generated from a sales order detail with a quantity in an inventory packaging unit without a binding. the target quantity of production order is of packaging unit of sales order detail. Reservation for sales order detail is complete and refers to generated production order. Reservation is in base unit of measure. Reservation stays complete after receipt of goods of production order (changes to reservation against inventory). If receipt of goods is partial, reservation of sales order detail is reserved against inventory as well as against production order (for not reported quantity).
RFR-016485 Correction
Framework: Production
Application: Production orders
View: n.a.
Action: validate
Category: Unexpected behavior
Problem: A production order can link itself manually to a sales order in case the production order type is configured to require a manually entered reference to a sales order.
It was possible to link to a sales order position that already was linked to an automatically generated production order.
I was also possible to specify a non-existing sales order detail.
In case the quantity of the production order was not identical to the sales order position and the reference was entered manually, the error message was misleading.
In case the production order was generated by a sales order for a production order type with option “Manual order reference necessary” enabled the sales order detail field was editable in the production order.
Correction result: A validation was added to prevent manually linking to a sales order detail that is already linked to an automatically created production order.
A validation prevents linking to a non-existing sales order detail.
There is a new message informing about deviating quantities case the production order links manually to a sales order. It does not mention that the production order was created by the sales order, because it should not have been created by a sales order.
In case the production order was generated by a sales order for a production order type with option “Manual order reference necessary” enabled the sales order detail field is not editable anymore in the production order.
Instead, all sales order identification field in production order header are fully editable in case “Manual order reference necessary” enabled and the sales order detail does not reference the production order.
RFR-016485 Correction
Framework: Production
Applications: Cockpit: Equipment, Cockpit: Equipment Reservations
View: Production equipment
Actions: “Generate inventory requisition for reprocessing”, “Generate inventory requisition for return transfer from reprocessing order”, “Generate inventory requisition for decommissioning”, “Generate inventory requisition for provisioning”, “Generate return transfer order”
Category: Unexpected behavior
Problem: During generation of inventory requisition, if there was any error or warning regarding the warehouses, an empty inventory requisition was generated.
Correction result: If an empty inventory requisition were to be generated, it is not generated at all now.
RFR-016485 Correction
Framework: Production
Application: Production issues
View: n.a.
Action: “Post production issues”
Category: Unexpected behavior
Problem: The application “production issues” crashes with an IllegalArgumentException, if a second user session has deleted the underlying production order, just shortly before the post of the production issue is being executed.
Correction result: The application does not crash any more. Before the post update, it is checked if the production order is still available. If not, the message GEN-5574 (Voucher type/header XY or at least one of the voucher line items no longer exists.) will be shown.
RFR-016485 Correction
Framework: Production
Application: Order maintenance, Cockpit: Production orders
View: n.a.
Action: Block
Category: Unexpected behavior
Problem: A production order has details of type material. This has availabilities/reservations at production warehouse (due to picking or possible surplus quantity by over picking). If this production order is blocked, availabilities for production warehouse are not blocked.
A possible result may be that for affected materials planning makes recommendations although production order is blocked. (*)
Correction result: In above-described scenario availabilities of material at production warehouse have status “Blocked” after production order has been blocked. Planning makes no recommendations that affected material causes.
(*) Please note: If planning uses an availability rule which only allows demands of production orders of status “in process” and “Released” wrong recommendations may be created if availabilities of a production order which is blocked do not have proper status.
RFR-016485 Correction
Framework: Production
Application: Production order types
View: n.a.
Action: n.a.
Category: Unexpected behavior
Problem: Cross-site option was hidden if organization in right upper corner does not support cross-site manufacturing.
Possibility of using cross-site option depended on organization in right upper corner, but production order types has not got organization.
There was a possibility to change “Production warehouse” to the one with organization that does not support cross-site and enable cross-site for the same type at the same time.
Correction result: Cross-site option is now always visible independently of an organization. Possibility of using cross-site option now depends on organization of “Production warehouse”. If organization of “Production warehouse” does not support cross-site manufacturing and at the same time cross-site option is enabled, an error message will be sent.
RFR-016485 Correction
Framework: Production
Application: Receipt of goods, Reject postings
View: n.a.
Action: Post
Category: Unexpected behavior
Problem: A production item has parallel units. If a receipt of goods for a production order is performed, where beside reported quantity a scrap or reject quantity is specified, the parallel units are rejected by validation (PRD-2548).
Correction result: In above-described context a receipt of goods of a production order with specification of scrap/reject quantity can be posted successfully.
5.1.7.1 External manufacturing operation postings
RFR-016485 Correction
Framework: Production
Application: External manufacturing operation postings
View: n.a.
Action: Ship to external manufacturer
Category: Exception
Problem: Performing action “Ship to external manufacturer” when distribution order is already completed caused exception and CEE crashed.
Correction result: Now performing this action shows correct error and CEE does not crash anymore.
5.1.7.2 Production issues
RFR-016485 Correction
Framework: Production
Application: Production issues
View: n.a.
Action: Post
Category: Unexpected behavior
Problem: Production issues internally are performed as a two step action. If the context of a production issue requires reservations ahead of posting these are done in a first step. Only if this first step is successful a confirmation dialog asks for posting. If the user does not confirm, posting is not performed and reservations/availabilities may have been set and will remain if user does not perform this posting anew.
Correction result: The confirmation dialog only asks for posting if validations for the action are successful. If confirmed the action is executed without any further interruption.
Please note: Some use cases where above described “first step” is performed: 1. Picking context; no picking so far but posting is done with warehouse = production warehouse (in case of reservation active) or any allowed warehouse (in case of reservation not active).
2. No picking context; material is of type identifier; identifier is not specified in production order detail.
RFR-016485 Correction
Framework: Production
Application: Production issue
View: n.a.
Action: Post…
Category: Unexpected behavior
Problem: Context: without reservation – in this case warehouse of production issue can be edited; over delivery of picking is not active.
A production order has a material for which picking is necessary. Before picking is done a production issue is performed with warehouse = production warehouse.
After this production issue is canceled with warehouse = issuing warehouse (=warehouse of production order detail).
Result: After cancellation two availability entries are generated: one for production warehouse, one for issuing warehouse. This is wrong.
Correction result: In above described context after cancellation a availability entry is generated for issuing warehouse with proper quantity.
5.1.7.3 Production orders
RFR-016485 Correction
Framework: Production
Application: Sales orders/Production orders
View: n.a.
Action: Sales order maintenance: Generate production order
Category: Unexpected behavior
Problem: A sales order details unit of measure (uom) is an inventory managed packaging unit. The packaging unit is binding. If for this sales order detail a production order is generated the quantity of production order is in base unit of measure of product/sales item. If reservation is active production order cannot be reserved for sales order detail as unit of measures deviate.
Correction result: If in above-described context a production order is generated from sales order detail the target quantity of production order is of packaging unit of sales order detail. Reservation for sales order detail is complete and refers to generated production order. Reservation stays complete after receipt of goods of production order (changes to reservation against inventory). If receipt of goods is partial, reservation of sales order detail is reserved against inventory as well as against production order (for not reported quantity).
If a production order is generated from a sales order detail with a quantity in an inventory packaging unit without a binding. the target quantity of production order is of packaging unit of sales order detail. Reservation for sales order detail is complete and refers to generated production order. Reservation is in base unit of measure. Reservation stays complete after receipt of goods of production order (changes to reservation against inventory). If receipt of goods is partial, reservation of sales order detail is reserved against inventory as well as against production order (for not reported quantity).
RFR-016485 Correction
Framework: Production
Application: Production orders
View: n.a.
Action: Calculate availability
Category: Exception
Problem: When there was more picked material than its target quantity value in production order and action “Calculate availability” was performed, an exception occurred.
Correction result: “Calculate availability” action performs correctly in this situation now and an exception is not thrown.
RFR-016485 Correction
Framework: Production
Application: Production orders
View: n.a.
Action: Duplicate in Position editor
Category: Exception
Problem: Trying to duplicate line items of type operation or resource with quantity 0 by using duplicate action in Position editor caused exception.
Correction result: Duplicate action in position editor does not cause exception anymore for operations/resources with quantity 0.
RFR-016485 Correction
Framework: Production
Application: Import data
View: n.a.
Action: Import data
Category: Exception
Problem: Importing production orders formulas with multiple line items, where some of this line items have empty fields about formula information causes an exception.
Correction result: During import of formulas line items without any information about formulas are now skipped. If this information is not completely empty but there are missing required fields, the error will be sent with information which fields are missing.
RFR-016485 Correction
Framework: Production
Application: Receipt of goods
View: Production
Action: Post receipt of goods
Category: Unexpected behavior
Problem: Calculation of expiration date used the current date instead of receipt of goods date.
Correction result: Calculation of expiration date uses receipt of goods date now.
Technical information: Incompatible changes required to provide the receipt of goods to the date calculation logic.
RFR-016485 Correction
Framework: Production
Application: Production issues
View: n.a.
Action: “Post production issues”
Category: Unexpected behavior
Problem: The application “production issues” crashes with an IllegalArgumentException, if a second user session has deleted the underlying production order, just shortly before the post of the production issue is being executed.
Correction result: The application does not crash any more. Before the post update, it is checked if the production order is still available. If not, the message GEN-5574 (Voucher type/header XY or at least one of the voucher line items no longer exists.) will be shown.
RFR-016485 Correction
Framework: Production
Application: Order maintenance
View: n.a.
Action: Dispatch
Category: Unexpected behavior
Problem: A product P’s bill of material contains a semi-finished product SP. This is assigned to an operation via a specific production plan. Routing for product P has operations O1, O2, O3,.. Routing for semi-finished product has operations O11, O12,…
If a production order of product P is scheduled FORWARD multiple level in order there can be situations where the first operation O1 of process structure of product P has a deactivated checkbox “Predecessor exits” although there is an operation as predecessor.
This happens if semi-finished product SP is assigned to first operation O1.
Consequence of this situations is that rescheduling this production order has a different result compared to dispatching as the operations O1 with deactivated “Predecessor exists” do start together with first operation O11 of semi-finished product.
This is wrong as operations of semi-finished product must be processed before the operation of product P which contains semi-finished product (here operation O1).
Correction result: In above-described situation production order detail representing the operation containing semi-finished product get an activated checkbox “Predecessor exists”. Thus, a rescheduling will work as expected and fist operation O1 only starts when las operation of semi-finished product ends.
Please note: If in above-described example semi-finished product is assigned to operation O2 (or O3, ..) the first operation of semi-finished product (O11) will start at the same time as operation O1 (of product) if scheduling category is FORWARD multiple level in order. This behavior has been untouched by this correction.
5.1.7.4 Resources
RFR-016485 Correction
Framework: Production
Process: Working with resource reservations e.g. reserving in production orders or rescheduling in resource allocation
Category: Unexpected behavior
Problem: Validation of calendar checked only first and last year of given range.
Resource reservations could only be scheduled for plus/minus 5 years (determined by SystemProperty) from the current year.
Correction result: Validation of calendar checks first, last and all years in between of given range.
Resource reservations can now be scheduled for as many years as the calendar has created years.
Technical information: Many resource related time ranges are limited to ‘n’ years into the past and future for safety. The ‘n’ is determined by the SystemProperty “com.cisag.app.production.scheduling.log.ResourceLogicImpl_SchedulingTimeHorizon”. The default was changed from 5 to 100.
5.1.8 Purchasing
5.1.8.1 Purchase orders
RFR-016485 Correction
Framework: Purchasing
Applications: Purchase orders, Supplier invoices
Action: Complete delivery manually
Category: Exception
Problem: If a purchase order has some supplier invoices but all of them are reorganized and some line items are not completely delivered an exception occurs during the try to determine the “cost transaction type” by the relevant supplier invoice type.
Correction result: In case of reorganized supplier invoices the supplier invoice type will be determined now with the help of the document reorganization data. If no supplier invoice type can be determined the same occurs as in the case that no supplier invoice is present.
5.1.8.2 Supplier invoice types
RFR-016485 Documentation
The following help documents have been updated regarding new user interface: – Eingangsrechnungsarten
– Vorgehensweisen: Eingangsrechnungsarten
– Eingangsrechnungen
The following help documents are contained in “Eingangsrechnungen” and are therefore no longer visible:
Zusatzkostenrechnungen, Eingangsrechnung ohne Belegbeziehung, Zusatzkostenrechnung aus Verteilung, Korrektureingangsrechnung, Konsigntations-Entnahmerechnung.
5.1.8.3 Supplier invoices
RFR-016485 Correction
Framework: Purchasing
Application: Supplier invoices
Action: Import
Category: Exception
Problem: If a supplier invoice has some persistent “Delivery slip number” data and the import file contains also some “Delivery slip number” data but not all the persistent state data an exception occurs.
Correction result: Now the exception does not occur any more in this case.
5.1.9 Sales
5.1.9.1 Customer contracts
RFR-016485 Correction
Framework: Sales
Application: Customer contracts
Action: Find and add line items
Category: Invalid data / Unexpected behavior
Problem: If the “Customer contracts” are using with respect to the contract type retail prices the value of the “End consumer prices” field within the “Find and add line items” dialog is not also true for the source order types “Customer proposal” and “Sales order”.
Correction result: Now the “End consumer prices” field has the correct value also for the source order types “Customer proposal” and “Sales order”.
RFR-016485 Correction
Framework: Sales
Application: Sales contracts
Action: Determine tax code
Category: Exception
Problem: An exception occurs during the try to determine a line item tax code for sales contracts that are using the retail calculation. The exception occurs if the same contract maintenance instance is used for different sales organizations.
Correction result: Now the exception does not occur any more.
5.1.9.2 Customer invoices
RFR-016485 Correction
Classes: com.cisag.app.(sales/multiorg).invoice.log. Invoicing
Method: normalizeNetAmountDomestic
Description: Within the loop with “CustomerInvoiceAccountingInfo accInfo” the variable “toBeDistributedTaxInfo” was used instead of the variable “toBeDistributedAccountingInfo” – so in some cases a NullPointerException occurs before this correction.
5.1.9.3 Sales – General
RFR-016485 Correction
Framework: Sales
Application: Freight cost calculation
View: n.a.
Action: n.a.
Category: Invalid data / Unexpected behavior
Problem: Freight cost calculations based on definitions of type ‘Freight cost classification’ or ‘Carrier + Freight cost classification’ provided incorrect values if price definitions were made on different hierarchy levels in the same hierarchy.
Correction result: From now freight cost calculations based on definitions of type ‘Freight cost classification’ or ‘Carrier + Freight cost classification’ will calculate as expected.
RFR-016485 Documentation
Following help objects have been updated:
– Auftragsbestätigungen abfragen
– Ausgangsrechnungen abfragen
– Pro-forma-Rechnungsarten
– Vertriebs-Schnellerfassungsbelegarten
– Vertriebs-Kontraktarten
– Vertriebskontrakte reorganisieren
– Positionen suchen und hinzufügen
5.1.9.4 Sales orders
RFR-016485 Correction
Framework: Inventory Management
Application: Sales orders
View: n.a.
Action: Reserve inventory quantities…
Category: Exception
Problem: If there were not referenced demand data and the action “Set default reservation quantities” was used the execution of the reservation action would cause an exception.
Correction result: The dialog will not consider already completed demand data and such not referenced demand data will be created no more as expected.
Data update: A new data update is not necessary because the application “Reorganize Availability and Requirement Data” can be used to delete those not referenced data. It is recommended to restrict the execution e.g. only for sales orders and the concerned item.
RFR-016485 Correction
Framework: Sales
Application: Sales orders
Action: Change line item delivery customer
Category: Unexpected behavior
Problem: If a sales order confirmation is present and the output settings for “Delivery slip” has the value “E-mail” the “delivery customer” of the line items cannot be changed to another value because the warning “SAL-01747” cannot be confirmed.
Correction result: Now the warning can be confirmed for the line items as expected.
5.1.10 Storage Location Control
5.1.10.1 Inventory orders
RFR-016485 Correction
Framework: inventory management
Application: Inventory requisitions and Inventory orders
View: Manual inventory movement
Action: 1. Validate a new line item in a not persistent inventory requisition
2. Save and report
Category: Exception
Problem:
1. The validation of a new line item in a not persistent inventory requisition led to an exception.
2. The reporting of an inventory order for a not released stock led to an exception.
Correction result:
1. Validating of a new line item in a not persistent inventory requisition no longer leads to an exception.
2. The reporting of an inventory order for a not released stock is now possible.
5.1.10.2 Storage location types
RFR-016485 Correction
Framework: Storage Location Control
Application: Storage location types
View: n.a.
Change the attribute values which belongs to inventory count processes
Category: Unexpected behavior
Problem: These attributes could only be changed if the type was not persistent.
Correction result: These attributes can be changed everytime as expected. New storage locations of this type will always overtake these values as defaults. After that these values can be overwritten for every storage location.
5.2 System development
RFR-016484 Ergonomics
German UI texts have been corrected.
RFR-016483 Correction
In com.cisag.sys.development.cockpits.log. PluginExportCockpitCreateBatch
the messages are send correctly to the job log
but the return value ignores whether it is a succuss or not.
Standard error
RFR-016483 Correction
Framework: Software development
Application: development objects
View: oql-views
Action: generating oql-view using tool crtbo
Category: Exception
Problem: In the case of an oql view using sub selects in the ‘where’ clause it can happen that the parser eleminates white space
when it shouldn’t. In such a case execution of the resulting statement on the database leads to an sql exception.
Correction result: The defined oql string is now correctly translated to an sql string.
RFR-016483 Correction
Framework: System Management
Application: Import data, Export data
View: n.a.
Action: n.a.
Category: Unexpected behavior
Problem: Incorrect default values for selected file type on the export data, Import data, Export data dialog, Import data dialog.
And on the Export data dialog, Import data dialog after executing the parameter and closing the dialog and open dialog again, the executed parameter will be not available.
Correction result: Default values for selected file type are correct. After closing the export data dialog, import data dialog, the executed parameter will be available.
RFR-016483 Correction
Framework: Workflow
Action: resolving greeting formula for mail
Category: Exception
Problem: The content language was taken from the CisEnvironment and not from the database parameter.
If the environment has no OLTP database, then an exception was thrown.
Correction result: The content language is now taken from the database parameter. Should this fail due to invalid usage then the customizing formula will be used instead.
RFR-016483 Correction
Framework: n.a.
Application: n.a.
View: n.a.
Action: n.a.
Category: Exception
Problem: Sometimes an exception will be thrown at clicking on the property of an error message.
Correction result: There is no exception anymore.
RFR-016483 Correction
Framework: n.a.
Application: n.a.
View: n.a.
Action:n.a
Field/Column: n.a
Category: New Method
Description: New Method “isBusinessObject(byte[])” in RepositoryInfo.
5.2.1 Application server
5.2.1.1 Logs
RFR-016483 Correction
Framework: System Management
Application: Message logs
View: n.a.
Action: n.a.
Category: Unexpected behavior
Problem: Sometimes, dependent field on the message log entries properties dialog was empty, although there is a dependent value.
Correction result: Dependent field works properly.
5.2.2 Configuration
5.2.2.1 System cockpit
RFR-016483 Correction
Framework: System Management
Application: System cockpit
View: Application server
Action: Refresh
Category: Exception
Problem: If category “Application server” is selected, the “Name” field is empty, and “Refresh” is selected, the application closes, and an exception message “java.lang.RuntimeException: No system guid and no system field available.” is displayed.
Correction result: The problem is resolved.
5.2.3 Data exchange
RFR-016483 Correction
Framework: System management
Application: Data exchange log entries
View: n.a.
Action: “Open correction application…”
Category: Unexpected behavior
Problem: Problem for import file in “.xls” und “.csv” format
Correction result: It works properly now.
5.2.4 GUI
RFR-016483 Correction
Framework: System management
Application: Webserver / UI applications
View: n.a.
Action: n.a.
Category: Unexpected behavior
Problem: After updates or if a local application is started consecutively for different CEE versions, applications may not correctly displayed in the browser because the browser still uses old or previous versions of certain files.
Correction result: Fixed.
Technical information: The path of CEE UI resources (CSS, JS, . ..) usually contains a version component, which forces the browser to fetch the right version of a given file instead of using an older version from the cache. For some CSS files this version component was missing.
5.2.5 System – General
RFR-016484 Correction
Library updated: postgresql-42.7.1.jar, mssql-jdbc-12.4.2. jre11.jar.
RFR-016484 Correction
Framework: All
Application: All adaptable cockpits
View: n.a.
Action: Refresh
Category: Exception
Problem: If too many search parameters are used, an exception occurs and the cockpit is terminated.
Correction result: The exception does not occur and an error message is displayed.
RFR-016483 Correction
Library updated: postgresql-42.7.1.jar, mssql-jdbc-12.4.2. jre11.jar.
RFR-016483 Correction
Framework: All
Application: All adaptable cockpits
View: n.a.
Action: Refresh
Category: Exception
Problem: If too many search parameters are used, an exception occurs and the cockpit is terminated.
Correction result: The exception does not occur and an error message is displayed.
5.2.6 Web server
RFR-016484 Correction
Update Webserver to Jetty 10.0.20
RFR-016483 Correction
Update Webserver to Jetty 10.0.20
5.2.7 Workflow
RFR-016483 Correction
Framework: Workflow management
Application: Activity definitions
View: Individual activity
Action: Creating activity to open cockpit with filled filters
Category: Correction
Problem: When the user chooses a cockpit application, there are parameters to fill out with filter values, which should be automatically set in application after open activity. Fields with data type Filter[bool] related to multi-valueset fields are not set in application.
Correction result: Fields with data type Filter[bool] related to multi-valueset fields should be set in application.
5.2.7.1 Activity definitions
RFR-016483 Correction
Framework:Workflow
Application: Activity Definition
View: “n.a.”
Action: Accept activity definition (AD)
Category: Exception | Invalid data
Problem: On pressing the “Accept activity definition” button, a NullPointerException is thrown and application itself crashes, although a new activity definition is accepted and present in system.
Correction result: Behaves as it should: on pressing the corresponding button, a new activity definition is copied in the current system and shows up immediately in the application.
Technical information: After an activity definition duplication, system loads an old activity definition. A UI update in between was forgotten.
5.2.7.2 Data model
RFR-016483 Correction
Framework: Workflow management
Tool: Workflow toolbar
View: n.a.
Action: Complete current task, Close current task unprocessed
Category: Correction
Problem: When user changes data in application without saving and next completes or closes the task, data will be lost and old version of object will be loaded.
Correction result: When user changes data in application without saving and next tries to complete or closes the task, a confirmation dialog will be shown.
5.2.7.3 Processes
RFR-016483 Correction
Class: com.cisag.sys.kernel.parser.StringFunctions. ReplaceExpression
Method: “n.a.”
Description: A new subclass ReplaceExpression in StringFunctions replaces substrings within a string, whereby the replacement is global for the string. There are two ways to set a pattern: 1. only a string in “quotation marks”. 2. additional int argument, so-called flags (int). The pattern is recognized in the Java way.