Send to Batcher



Overview

This is the second step in the ERP/Repete CNX integration.

  1. Create Batch

  2. Send to Batcher

  3. Receive from Batcher

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

  1. Create the PO scheduled deliveries in ERP

  2. Create a PO scheduled delivery batch

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

Field Name

Populated Value

Notes

Field Name

Populated Value

Notes

TicketNumber

PO#- ItemCode - DeliveryDate

AAI-1321: The ticket number is populated with the concatenation of PO#, item code and delivery date.

LotNumber

PO#

AAI-1321: The PO #.

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.

References

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.