Send to Batcher
Overview
This is the second step in the ERP/Repete CNX integration.
Create Batch
Send to Batcher
Receive from Batcher
Commit to ERP
In this step, the PO scheduled deliveries are sent to Repete CNX using OData protocol. This process will create tickets and receipts on Repete CNX system. Thereafter, the people on the Repete CNX side will need to move the process along.
Configuration
For this integration with RepeteCNX, we created a new product entry in lkpIntegrateProduct.
For the actual configuration, a new entry has to be entered in the table ConfigConnect, something like below.
Note, for the DataSource, the URI would be something like http://MyRepeteHost:port/CNX
. An example would be http://96.11.7.123:4444/CNX.
To test out the connection, issue the request http://96.11.7.123:4444/CNX/Receiving/$metadata.
Security
A few security domains were added for the integration. The user will need "Send/Receive Batcher" permission to be able to send.
Workflow
These are the normal workflow necessary before the Send to Batcher can be done.
Create the PO scheduled deliveries in ERP
Create a PO scheduled delivery batch
Bring up the batch
Once the batch is brought up, the scheduled deliveries are ready to send to Repete CNX (Send Completed is unchecked).
If the send is successful, the Send Completed field would be checked and the rest of the Send band are populated with data. Note, scheduled deliveries can only be sent once.
The Ticket Number is one of the most important numbers of this whole process, as it is the unique identifier that we use to receive against. This number cannot change, otherwise we will never be able to report completion back to ERP.
After the initial development, we were setting the ticket number as a unique integer key, and passing it to RePete. However, our customers informed us that RePete also uses this ticket number in lookups to select and view details on our sent purchase orders. These lookups became untenable, as the users who need to process these POs receive no context from these unique identifiers.
For this reason, we changed Connect to generate ticket numbers that have some context, that are still unique identifiers for us. Ticket Numbers are generated in a [PO#]-[Date] [ItemDesc] format. The RePete interface only accepts numbers of 20 characters, so we truncate the description when we hit this length. This number is set on the purchase order itself, based in the delivery date and ingredient of the first purchase order line. This gives users of Repete a little more of the context they need to navigate their POs.
It is important to stress once more, that Connect does use this number as a unique identifier. Once we had to make this change and deploy it, any POs that are not in a completed state will not be able to be completed, as the service will now be looking for ticket numbers with the updated format.
Field Values
These are the special populated values requested by the customer.
Repete CNX Website
The kind folks from Repete provided us a test machine. Their test machine URL is 96.11.7.123/RepeteMiiWebService/Web Pages/Login.aspx. Once logged in, click on the "Receiving Ticket" button.
This will take us to the list of receiving tickets. The newly created tickets/receipts should be at the very end of the list.