None
This Business Object allows for a single stock item to be moved from one Tracking Id to another Tracking Id. Should the destination Tracking Id exist in a different Bin or Warehouse as the source Tracking Id, a Bin to Bin transfers or Warehouse transfer will be performed in SYSPRO automatically.
If you don’t like reading, you can watch the video.
Description
Business Object to move stock from one Tracking Id to another Tracking Id.
Code | WMOVE003 |
|---|---|
Name | TrackingIdConsolidation |
Module | WarehouseMovements |
Functional Area | TrackingID |
Name Space/Class | DATASCOPE.SDK.BusinessObjects.WarehouseMovements.TrackingId |
Release Date | 03/05/2019 |
Release Version | 5.0.0.60 |
Prerequisites | None |
|---|---|
SYSPRO Objects | Transaction.INTMB, Transaction.INVTMO |
Parameters
Name | Description | Mandatory field | Data Type | Default Value |
|---|---|---|---|---|
pTrackingid | WMS Tracking Id to move stock from | Yes | string | N/A |
pDestinationTrackingID | WMS Tracking Id to move stock onto | Yes | string | N/A |
pStockCode | Stock Code to be moved | Yes | string | N/A |
pQuantity | Quantity to move from the source to destination | Yes | decimal | N/A |
pConsolidationModule | Module to reflect in the Tracking Id history for the transaction | No | enum | BIN_TO_BIN |
pDestinationHash | Destination Hash code if validation on the destination is required | No | string | <blank> |
Technical Specification
<sample code>
Example to follow
In this example, we will create a TrackID Consolidate and call the Object from the application.
What we are interested in is to see which Properties Mandatory fields are required for this Business Object. These will be the basic Properties that we must set up on the Object.
Another important thing to take note of is the SYSPRO Objects that are required. When calling a DATASCOPE WMS Object it might or might not call a SYSPRO Object in the background. For the TrackIConsolidation Business Object, it can either be the Transaction.INTMB or Transaction.INVTMO SYSPRO Objects. Therefore, if we post a TrackID Consolidate, TrackIDs that are in different Bins can either be invoke a SYSPRO Bin transfer (Transaction.INTMB), or if they are in different Warehouses, we will invoke a Warehouse transfer (Transaction.INVTMO).
It is, therefore, always important to take note of the SYSPRO Objects required, as the Operator doing the post must have the required permissions in SYSPRO.
Note: For an overview of Modules and Functional Areas, refer to the Functional Areas and where our Business Objects live
Open the BO Demo Application
We will continue to work on our BO Demo application in Visual Studio. Refer to How to develop a Simple Application
Add buttons and text fields to the Form.
Additional buttons and text fields must be added to the form for the TrackID Consolidate.
These would typically be the Mandatory Properties indicated in this Parameter list.
Remember to update the Label and Name under Properties.
Add code to the form.
Select the Form1.cs tab at the top of the screen.
Step 1 – Validate we have a GUID
First, we must start to confirm that the GUID is not blank, as you cannot post without a valid GUID.
Step 2 – Instantiate the Object
Start by adding DATASCOPE.SDK.BusinessObjects. to your code. Next, you can refer to the Reference Sheet, Name Space/Class column, to know what must come next.
Again, you can prefix the Object with an ‘o’. For Example, oTrackIDBO.
Enter the oTrackIDBO Business Objects and instantiate it. Nothing will go into the constructor; it will just be an empty constructor.
Step 3 – Set the Properties
Next, you must start to define the properties of the Business Objects. All our Objects Properties are prefixed with the letter ‘p’, so start by entering your Object name, for example, oTrackIDBO.p, and a list of all Properties applicable to the Business Object will display.
These Properties must then be set to the various text boxes you have created earlier in Form1.cs [Design] Tab.
Step 4 – Post the Object
Again, start by entering the Business Object, oTrackIDBO, and refer to the Reference Sheet to see what Method to use.
Notice that this requires a GUID, and we will use the existing GUID (txtGUID) in the form.
Enter the GUID, as we already validated it in Step 1.
You will also require a response Object. All our Business Objects will respond with this specific Object, which contains information about whether the call was successful, what information it’s returning, or any error messages.
Step 5 – Error Management
The response will come back into the oResponse object. This is just a generic object that comes back depending on the business object that will have a set amount of data. In this case, it will just return a string, which we will display in the GUID.
Your app should be ready to build now.
Right-click on the form name under the Solution Explorer.
Select Build
Copy the entire folder (in our example, Debug) and paste it on the DATASCOPE WMS Server.
Run the application.
Open the BODemo.exe file.
The Form will open, and you can start entering data into each field.
Note: To test your new application, you must ensure you have the correct data in the core DATASCOPE WMS product to work with. You can always look at the Information Check screen.
Again, log in with our Operator to get a GUID.
Next, enter the From TrackID and To TrackID numbers (data obtained from the Information Check screen)
Enter the Stock code, for example, A100.
Enter the Quantity.
Select Post.
To test whether your application was successful, you can go back to the Information Check screen, refresh the screen, and the stock should reduce with the Quantity entered in our application.
Basic Object Structure
All our Business Objects should follow the same structure:
Step 1 – Set the DATASCOPE WMS API End Point (this only needs to happen once per application)
Step 2 - Validate we have a GUID.
Step 3 - Instantiate the Object.
Step 4 - Set the Properties.
Step 5 – Post the Object.
Step 6 – Error Management.