Skip to main content
Sign in More

Spares API Integration Workflow

  • Updated

Technicians use L2L's maintenance system to manage abnormalities on the plant floor. All maintenance activities are recorded in an L2L Dispatch, which is similar to an ERP Work Order. Technicians request spare parts from the L2L Dispatch screen, and spare parts can be issued from the L2L Spares Queue screen.

Spares can be managed from within L2L or in another application, like an ERP. When spares are managed in an ERP system, spares records can be synced to L2L so they can be used by Technicians in the L2L Dispatch system. Consumption records can then be synced from L2L to the ERP system to complete the loop of spare part management.

Spare parts between L2L and ERP can be kept in sync using two automated processes. This document provides documentation to build these processes.

This document provides instructions to integrate ERP Spares with L2L Spares. This includes synchronizing spares consumption records from L2L to ERP. Documentation is also provided to synchronize L2L Dispatches with ERP Work Orders if this is required by the ERP.

Process Workflow Chart

The following process workflow chart is a typical workflow of spare part records in a plant. The integration application is represented by yellow boxes in the flowchart.

Spares_Integration_Workflow.jpg

 

Middleware Integration Application

Synchronize Consumption Records

This is the process by which spares requests from L2L are inserted into ERP as consumption records. This process corresponds with step 2a in the flowchart above.

Objective: Consumption records are up-to-date in ERP.
Suggested Interval: 1-5 minutes
Process Outline - METHOD 1:

  1. Pull new spares request records from L2L. 
    GET https://[customer].leading2lean.com/api/1.0/spares/?auth=[api key]&site=[site id]&status__lte=3
    1. See list of spares statuses in the references section below.
  2. Insert each spares request record into ERP system as a consumption record.
    1. Attach the ERP consumption record to the ERP Work Order.
  3. Mark each spare record as “synchronized” on L2L as they are inserted into ERP. If the process is interrupted, parts that have been marked as synchronized will not be included in the spares request payload, and consumption records will not be duplicated. 
    POST https://[customer].leading2lean.com/api/1.0/spares/synchronize/[spare id]/?auth=[api key]
    1. POST Parameters: status=6
      1. See list of spares statuses in the references section below.

Process Outline - METHOD 2:
This is the preferred method if you are using Kitting functionality or if you are using the "On Order" and "Received" Spares Statuses.

  1. Identify the most recent time the synchronization process was completed successfully. Ideally this time is stored locally so that it can be re-run if the process is interrupted.
    If this is not possible, the following query will return the time of the last sync from L2L. This query must be capped to only consider spare requests that have synced within a week (or less) in order to keep the query performant. The synchronized_on property of the spare request returned will be used for the next step as the lastupdated__gte=[time of last sync] query parameter. 
    GET https://[customer].leading2lean.com/api/1.0/spares/?auth=[api key]&site=[site id]&synchronized_on__gte=[one week ago]&order_by=-synchronized_on&limit=1
  2. Pull new spares request records from L2L.
  3. GET https://[customer].leading2lean.com/api/1.0/spares/?auth=[api key]&site=[site id]&lastupdated__gte=[time of last sync]&order_by=lastupdated
  4. Insert each spares request record into ERP system as a consumption record.
    1. Attach the ERP consumption record to the ERP Work Order.
  5. Set the synchronized_on date on the Spare record to indicate the Spare record has been synchronized. If you are storing the time of the last successful synchronization locally, use the current UTC time for synchronized_on. If you are not storing the time of the last successful synchronization locally, set synchronized_on to the Spare record's lastupdated value. This will allow the process to gracefully pick up where it left off if it does not complete successfully. You must pass in the Spare record's current status so that it doesn't automatically get set to synchronized.
  6. POST https://[customer].leading2lean.com/api/1.0/spares/synchronize/[spare id]/?auth=[api key]
    1. POST Parameters: synchronized_on=[lastupdated OR current UTC time]&status=[current status]

Additional Info:

  • This process will not be disrupted if the spares request is closed from L2L Spares Queue web interface before the records have been synced. Closing a spare request in the web UI and synchronizing the spare request through the API can happen in any order.
  • If you are using Method 1, L2L will automatically set the synchronized_on property to the current UTC time when you set the status to synchronized. This will make it easier to migrate to Method 2.

Synchronize Spare Parts

ERP is the system of record for a spare part. In order to provide associates on the plant floor with an accurate spare parts list, spares must be synchronized to L2L on a regular basis. This process corresponds with step 4 in the flowchart above.

Objective: All spare parts are up-to-date in L2L.
Suggested Interval: 1-5 minutes
Process Outline:

  1. Pull all spare records from ERP that have been updated since the last time the parts were synchronized. This will require you to keep track of when the synchronization tool runs.
  2. Update each spare part in L2L. 
    POST https://[customer].leading2lean.com/api/1.0/billofmaterials/inbound_sync/?auth=[api key]
    1. POST Parameters: site=[site]&partnumber=[part number]&description=[description]&location=[location]&quantity=[quantity]&minimum=[minimum]&optimum=[optimum]&cost=[cost]
    2. See API documentation for full list of parameters.
  3. Optional: Remove unused locations. When locations are removed from an ERP, they must also be explicitly removed from L2L.
    1. Gather a list of Bin Locations for a spare part. 
      GET https://[customer].leading2lean.com/api/1.0/binlocations/?auth=[api
key]&site=[site id]&billofmaterials=[bill of materials id]
    2. Inactivate unused locations and set quantity to 0. (This uses the same API method as step 2 above). 
      POST https://[customer].leading2lean.com/api/1.0/billofmaterials/inbound_sync/?auth=[api key]
      1. POST Parameters: site=[site]&partnumber=[part number]&location=[location]&quantity=0&active=false
  4. Optional: Add Vendor Information to the Part.
    1. Get the Vendor ID 
      GET https://[customer].leading2lean.com/api/1.0/vendors/?auth=[api key]&site=[site id]&name=[vendor name]
    2. Add a new record 
      POST https://l2l.leading2lean.com/api/1.0/billofmaterialsvendor/?auth=[api key]
      1. POST Parameters: site=[site]&billofmaterials=[bill of materials id]&partnumber=[vendor part number]&primary=[true or false]&vendors=[vendor id]

Synchronize Consumption Records with Work Orders (optional)

Use this process if consumption records must be attached to a Work Order in ERP. Because of the added complexity, synchronizing consumption records without Work Orders is preferred. This process is identical to the Synchronize Consumption Records process, with a few extra steps to integrate with Work Orders. This process corresponds with step 2a and 2b in the flowchart above.

Objective: Consumption records are up-to-date in ERP system.
Suggested Interval: 1-5 minutes
Process Outline:

  1. Pull new spares request records from L2L. 
    GET https://[customer].leading2lean.com/api/1.0/spares/?auth=[api key]&status__lte=3
    1. See list of spares statuses in the references section below.
  2. For each spares request, get the Dispatch object from L2L using the dispatch parameter in the spares request record. 
    GET https://[customer].leading2lean.com/api/1.0/dispatches/?auth=[api key]&id=[dispatch]
  3. If a Work Order has been created in ERP from the Dispatch, update it. Otherwise, Create a Work Order in ERP using the Dispatch details. See the Synchronize Work Orders process below for documentation on how to link an L2L Dispatch to an ERP Work Order
  4. Insert each spares request record into ERP system as a consumption record.
    1. Attach the ERP consumption record to the ERP Work Order.
  5. Mark each spare record as “synchronized” on L2L as they are inserted into ERP. If the process is interrupted, parts that have been marked as synchronized will not be included in the spares request payload, and consumption records will not be duplicated 
    POST https://[customer].leading2lean.com/api/1.0/spares/synchronize/[spare id]/?auth=[api key]
    1. POST Parameters: status=6
      1. See list of spares statuses in the references section below.

Synchronize Work Orders (optional)

Synchronizing Work Orders is usually not required for spares Integration. This process documentation is provided for Integrations that may require Work Orders to be synced for other reasons.

Objective: Work Orders created in L2L are synced in ERP.
Suggested Interval: 5 - 60 minutes
Process Outline:

  1. EITHER Pull all Dispatches from L2L that have been updated since the last time Dispatches were synchronized. 
    GET https://[customer].leading2lean.com/api/1.0/dispatches/?auth=[api key]&lastupdated__gte=[last synchronized date, YYYY-MM-DD+HH:MM]
  2. OR Pull all Dispatches from L2L that have been closed since the last time Dispatches were synchronized. 
    GET https://[customer].leading2lean.com/api/1.0/dispatches/?auth=[api key]&closed__gte=[last synchronized date, YYYY-MM-DD+HH:MM]
  3. If the Dispatch has already been added to ERP as a Work Order, update the ERP Work Order. Otherwise, create a new ERP Work Order.
    1. Store the ERP Work Order ID on the L2L Dispatch record. This will be used to identify if an ERP Work Order has been created for an L2L Dispatch. It can also be used to look up Dispatches by ERP Work Order ID. 
      POST https://[customer].leading2lean.com/api/1.0/dispatches/set_externalid/[dispatch id]/?auth=[api key]
      1. POST Parameters: externalid=[erp work order id]

References

  • API documentation can be found by logging into L2L as an administrator, click on the “Support” menu icon, and click “API Documentation.”
  • Spares Statuses:
    • 1. Issue Requested
    • 2. In Process
    • 3. Complete
    • 5. Deleted
    • 6. Synchronized
    • 7. On Order
    • 8. Received
    • 10. Kit Requested
    • 11. Kit Reserved
    • 12. Part Movement Requested
    • 13. Part Movement Approved
    • 14. Part Movement Shipped
    • 15. Part Movement Denied
  • Transaction Types:
    • 0. Consumption: Used any time a spare is issued through one of our spares request screens.
    • 1. Receipt: Used when parts are receive into the system via a PartOrder
    • 2. Inventory Adjustment: Used anytime a quantity is changed in the app via Inventory Control. This can be on the Part detail screen or the location detail screen.
    • 3. Part Order Received Cost Adjustment: Used when the cost is changed on a PartOrder. This transaction will only occur if the quantity_received in the PartOrder is > 0. This transaction is only used to represent a different in receipt costs and how it affects the on hand inventory.
    • 4. Part Order Consumed Cost Adjustment: Used when the cost is changed on a PartOrder and the quantity_consumed is > 0. This transaction is used in certain consumption reports such as the monthly report as it reflects a valid change in consumption costs that needs to be realized.
    • 5. Consumption Obsolete: Used when issuing a part that has been marked obsolete. Not reflected in monthly report but reflected in normal reporting.
    • 6. Obsolete Part Cost Adjustment: Used when marking a part as Obsolete. The cost of all existing inventory is included in this transaction and reflected in the monthly report. All subsequent issues
      are not reflected in this report. 
    • 7. Part Movement Consumption. Used when a part is transferred to another site. The other site will have a companion Part Movement Receipt transaction.
    • 8. Part Movement Receipt. Used when a part is transferred from another site. The other site will have a companion Part Movement Consumption transaction.

Frequently Asked Questions

1. There’s no Spares status for “Sync Error” or similar to designate back to the stockroom or IT that there was a problem syncing the spare request to ERP. 

Answer: You are correct, there is no status if there was an issue during the sync. The indication to the end user that the Spare Request record isn't synced is that it doesn't have a "Synced" status. In other words, if a part doesn't sync, it will still have the status of "Issue Requested" or "In Process." The tricky thing here is that a sync error can happen in many places. It is even possible that an error could occur in setting the spare request status. So, if the user sees spares records that are stuck in "Issue Requested" or "In Process," They should know that there is an issue with the syncing utility.

2. I chose an invalid consumption category when requesting the spare (Example: I chose an administrative consumption category for a dispatch/machine that is not administrative in JDE, so it errored correctly)a. As far as I can tell, there’s no way to edit the spares request to change the consumption category. Is that accurate? If so, how do I fix it?

Answer: You are correct, you cannot change a consumption category one a spares request has been created. You'd have to reverse the request and re-request the spare part. This is the preferred process when keeping a "ledger" type spares queue. If a requested part is no longer needed, the technician would return the part to inventory by requesting a negative quantity of that part, thus cancelling out the initial request.

3. Can consumption categories be dynamic like other areas of the system where I can tell L2L that dispatches for production machines only show Supplies or Repair categories, while dispatches for conference rooms or lawnmower machines only allow Administrative or Building/Grounds categories?

Answer: Consumption categories are not dynamic. If you need to enforce the connection between consumption categories and areas, you'll need to build that into your integration tool.

4. Can we lock down certain spares statuses? I don’t want anyone to change from “Complete” to “Synchronized” – only the integration should be able to do that.

Answer: We currently cannot lock down spares statuses. We typically don't have any problems with techs choosing the wrong status. We typically handle these types of issues with training.

5. Can we remove the “Close” button if a request isn’t at certain statuses? 

Answer: The "Close" button will set the Spares Request Status to "Complete". So, if a spare part is requested, issued, and closed before the integration tool picks it up, it will still show up in your list if you are filtering off of "status__lte=3". Then, once your integration tool is finished with it, you can set the status to 4, synchronized. It was built this way so that we didn't prevent the end user from issuing parts - the integration logic simply is a reflection of what happens in MRO.

6. I can only create one location per spare part. Can I create more than one location per spare part?

Answer: Yes. There is a Setting on the Spares → Settings screen that controls the number of locations available for a Spare part. If you want to add more than one location, ensure that the setting "Limit To One Location Per Part On Synchronization/Import" is disabled.

Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles