Known issues
Table of Contents
Missing support for Assembly BOM
Unfortunately, it's not possible to support Bill of Material Items of type Assembly in COBI.wms due to a limitation in SAP Business One:
Pre-Allocation of Batch and Serial Numbers for Pick Lists
If you want to decide for your warehouse employees which batch numbers or serial numbers they should pick, instead of letting them choose the batch or serial numbers themselves while picking, then you should be aware of the following issue.
Note: This issue only applies to Pick Lists without bin locations. If you're picking from a warehouse with bin locations, then this issue doesn't apply.
For an example, let's consider a Pick List based on a Sales Order, containing an item with batch numbers. The issue applies to other types of Pick Lists as well, and also to serial numbers, but we will use this scenario to explain the issue.
In SAP Business One, there are two ways you can pre-allocate batch numbers for the Pick List:
- Allocate the batch number only in the underlying Sales Order
- Allocate the batch number both in the Sales Order and in the Pick List
The second way is actually ideal, because the same Sales Order could have multiple Pick Lists that are based on it, so if you only allocated the batch in the Sales Order, it wouldn't be clear for which Pick List it is.
However, there is unfortunately a problem in the programming interface of SAP Business One, which prevents COBI.wms from updating a Pick List if it contains batch pre-allocations.
For this reason, you must only allocate the batch number in the underlying Sales Order, and not directly in the Pick List. If you have several Pick Lists based on the same Sales Order, your warehouse employees will see all batch numbers allocated in the underlying Sales Order.
Forcing a Recreation of COBI.wms Database Views (Dropping Views)
Background / Use Case
When customer-specific customizations have been made to COBI.wms or if data structures in SAP Business One have changed significantly, the app might not immediately recognize the new datasets. In such cases, the COBI.wms database views need to be refreshed or recreated.
How does the mechanism work?
Every time a user logs in via the MDE device (scanner), COBI.wms checks if a specific version view exists in the SAP company database (the view cwXX__version).
If this view is deleted (“dropped”), the app detects the missing view during the next login. COBI.wms will then automatically trigger a process that freshly recreates all COBI-specific views in the database. Outdated or incorrect views will be cleanly overwritten.
1. Identifying the correct View
The name of the view that needs to be dropped depends on the installed COBI.wms app version (the XX represents the version number).
| COBI.wms Version | Name of the View |
|---|---|
| 2.38 | cw38__version |
| 2.40 | cw40__version |
| 2.42 | cw42__version |
| 2.43 | cw43__version |
Note: This naming logic will continue for future versions.
2. Dropping the View
Depending on your database system (SAP HANA, MSSQL, or Azure SQL), execute the corresponding command against your SAP company database.
For Microsoft SQL Server (MSSQL) & Azure SQL:
Open the SQL Server Management Studio (SSMS), select the respective company database, and execute the following script (Example for Version 2.43):
DROP VIEW cw43__version;
(Alternatively, you can locate the view in the Object Explorer on the left under “Views”, right-click it, and select “Delete”).
For SAP HANA:
Open the SAP HANA Studio, select your company schema, and open the SQL console. Execute the following script (Example for Version 2.43):
DROP VIEW "cw43__version";
3. Rebuilding the Views
Once the view has been successfully dropped from the database, take your MDE device.
- Completely close the COBI.wms app.
- Reopen the app and log in.
- The login process will take slightly longer this one time (approx. 5-15 seconds) because all views, including the latest data structures and customizations, are being newly generated in the background.