Production API Integration: Actual and Scrap – L2L

The pitchdetails/record_details API method can be used to automate pitch data submission for a line. Many automated lines will use this method to decrease the amount of time a user must interact with systems.

Adding Production Actuals and Scrap

Objective: Automate addition of production details to L2L
Suggested Interval: 5 minutes
Process Outline:

Retrieve a count of good parts and defect parts that were created on a line within a specific interval
1. This information can generally be retrieved from a MES or SCADA system.

Submit the counts to L2L

GET https://[customer].leading2lean.com/api/1.0/pitchdetails/record_details/?auth=[api key]&site=[site id]&linecode=[line code]&start=[time if first part]&end=[time of last part]&productcode=[product code]

When implementing a solution that uses the pitchdetails/record_details API, please consider the following:

Best Practices

Adding Data

Be sure to consult the API documentation for the pitchdetails/record_details API for all the required fields. This is available from your home page under the SUPPORT tab.
Batch insert data for fewer API calls by summing metrics over a time period, (e.g. submit data once every 5 minutes instead of once every part). When batch inserting, do not overlap time periods. The start time property should reflect the time the first part was completed, and the end time property should reflect the time the last part was completed.
Each API call should represent a single product. Multiple products should be sent in separate API calls. Be mindful that the time frames for different products do not overlap.
Each pitch detail record will automatically be associated with the pitch that matches the time frame of the pitch detail record. In the event that a pitch detail record spans two different pitches, the end time will be used to determine which pitch to associate the data.
If a pitch has not been scheduled for the time, the API will create one. It will first use the default Pitch Schedule Template configured for the line to determine start and end times. If there is no default Pitch Schedule Template, the API will create a pitch using the start time from the record_details call for the start of the pitch, and the Default Pitch Length setting to calculate the end of the pitch.
It is not necessary to send pitch details with 0 actual and 0 scrap. The one exception is if you are updating an existing pitch details record (e.g. updating a pitch detail record from 5 scrap to 0 scrap).
Send pitch detail records in the same sequence that the parts were built. If they are sent out of sequence the pitches may be split incorrectly.
If you submit pitch details with more "actual" parts than the number of parts needed to complete the current Product Order (Build Sequence), the API will split the pitch detail record into two records: The first record will complete the current Product Order, and the second record will go toward the next Product Order.
If you have enabled 'Allow Operators to Over Build Orders' and the product in the new record details data is the same product as the line's current build sequence and there are no other build sequences in the queue for the current product, then the system will not complete the order and will continue to add pitch details to the current build sequence/order.

Updating Data

You may update a pitch detail record after one is created. Before inserting a new record, the API will first try to update any existing records with the exact same start, end, and productcode properties. If no records are found, the API will insert a new record.
If you update an existing pitch detail record, the API will not split the pitch detail record and apply parts to future Product Orders as it will when creating a new pitch detail record.

Removing Data

There is no way to delete a pitch detail record. You can, however, decrement actual and scrap totals by sending in negative numbers. This is the preferred method since it shows a full history of each API call. Be sure that you use unique start and end dates so it does not update a pitch record.

Changeovers/Splitting Pitches

When a pitch detail record is sent with a productcode that is different than the pitch's current product, the pitch will be split. The start time will be used for the start time for the new pitch. If the new pitch detail record has the same start time as another pitch detail record for a different product, the new pitch will take the pitch detail records from the original pitch, and the actual and scrap numbers will be decremented from the original pitch.
An administrator can turn off pitch splitting in the line settings. When pitch splitting is turned off, all parts will be attributed to the first part of the pitch. As a result, reports will be off. In order to get full value out of reports, we recommend you allow the API to split the pitch when possible.
This API will not set the demand of future pitches when splitting the pitch. Please see the documentation for /buildsequence/start_change_over/ method for that functionality.

Common Mistakes

The most common mistake is submitting data for two different products on the same line with the exact same start and end times or overlapping time frames. Always use unique start and end times. This provides a clear signal to L2L for where to split a pitch. Failure to follow this guideline will result in missing data on a pitch. Consider the following scenario:
- 5 parts of ProductA came off the line between 8:01:10 and 8:02:30
- 5 parts of ProductB came off the line between 8:03:15 and 8:04:45
- I will submit two calls to the record_details API:
  - /api/1.0/record_details/?productcode=ProductA&start=2020-01-02%208:01:10&end=2020-01-01%208:02:30&actual=5...
  - /api/1.0/record_details/?productcode=ProductB&start=2020-01-02%208:03:15&end=2020-01-01%208:04:45&actual=5...
Sending multiple pitch details for a single product with the same start and end times. This will update pitch data instead of appending a new record.
Not scheduling pitches.
Not configuring a default pitch schedule template for every line.
Submitting multiple record_details calls at the same moment. Calls should be sent in sequence. Wait for one response before sending another API call.