Skip to main content
Question

Numbering Sequences API Only Updating First Row

  • October 20, 2026
  • 7 replies
  • 31 views
  • Translate All

Forum|alt.badge.img

Hello - 

Via an API, we are trying to update the 7th row under the Details section on the Numbering Sequencing screen but only the first row seems to update even though the NumberingSEQ ID is being referenced. Is there something we are missing?

Thank you,

Ashley

7 replies

Steve Milner
Varsity III
Forum|alt.badge.img+6

@ashleyb NumberingSEQ is only half of that row's key. Each row on Numbering Sequences is keyed by Numbering ID plus NumberingSEQ, and the API needs both on the detail row before it can find it.

PUT /entity/<your endpoint>/<version>/Numbering?$expand=<your detail>
{
  "NumberingID": { "value": "APITEST" },
  "Sequence": [
    {
      "NumberingID": { "value": "APITEST" },
      "NumberingSeq": { "value": 10137 },
      "LastNumber": { "value": "A000200" }
    }
  ]
}

Use your own endpoint's field names. If Numbering ID isn't on your detail entity yet, add it on Web Service Endpoints (SM207060) with Populate.

The other option is the row's id. GET the record with the detail expanded, take the id of the row you want, and send that id in the PUT. Do it in the same session, because these rows have no note ID and the id changes with every login. An id from an earlier login failed for me.

I tested this on 2026 R1 with a custom endpoint and a numbering with 7 rows. Both payloads updated row 7 and nothing else. NumberingSEQ on its own was rejected outright rather than landing on row 1, so if row 1 keeps changing, compare your payload to the one above.

Translate

Forum|alt.badge.img
  • Author
  • Varsity I
  • October 20, 2026

Hi ​@Steve Milner - We can’t seem to get it to work... One thing I forgot to mention is we currently have it set to Auto # however our purpose of doing this is to Manual # one of the rows instead. Do you think this could be interfering?

Translate

Steve Milner
Varsity III
Forum|alt.badge.img+6

@ashleyb No, Auto numbering isn't what's blocking it. My APITEST numbering had Manual Numbering cleared, same as yours, and the row 7 update went through.

Manual Numbering isn't a row setting, though. It's the check box in the Summary area of Numbering Sequences, it belongs to the numbering ID, and it covers every row under that ID. A detail row only holds Branch, Start Number, End Number, Start Date, Last Number, Warning Number and Numbering Step, so there's nothing on row 7 that makes only that row manual, through the API or on the screen. Checking Manual Numbering turns it on for every document that uses that numbering ID, and each of those then needs its number entered by hand.

If you still need the row update itself, post the request body and the response you get back. A failed PUT returns an error message, and that will show where it's getting stuck.

Translate

anahizentella94
Jr Varsity III
Forum|alt.badge.img

​@ashleyb b Adding to Steve’s answer: the Auto/Manual setting isn’t what’s blocking you, but it does change what you’re trying to achieve.

Manual Numbering can’t be set per row. It’s a header-level setting on Numbering Sequences (CS201010) and applies to every subsequence under that Numbering ID. The detail rows only hold Branch, Start/End Number, Start Date, Last Number, Warning Number and Numbering Step. So even once the PUT updates row 7, it won’t make only that row manual.

Depending on what row 7 represents, a few options:

  1. You need a different next number for that branch/subsequence. Just update LastNumber on row 7. That’s the PUT Steve described, with the full row key (NumberingID + NumberingSeq) or the row id taken from a GET in the same session.
  2. You need manually entered numbers for a subset of documents. Create a separate Numbering ID with Manual Numbering checked, and assign it where the module allows numbering by type (for example, a dedicated Order Type in Sales Orders).
  3. You need manual numbering for one branch on a document type that has a single numbering setting. That requires a customization that overrides the auto-numbering behavior for that branch. It isn’t something the API or the screen supports out of the box.

Could you share which document type uses this numbering and what row 7 is (e.g., a specific branch)? That will tell us which option fits.

Translate

Forum|alt.badge.img
  • Author
  • Varsity I
  • October 22, 2026

Hi ​@anahizentella94 - I believe option 3 is likely what we need. Are you able to share any guidance on how to achieve this?

We are trying to update the POORDER which is set to auto number, to manually update for only one specific Branch (line 7). See Request Body we have been sending but keep receiving error “exceptionMessage": "More than one entity satisfies the condition.".

 

{

  "NumberingID": { "value": "POORDER" },

  "Sequence": [

    {

      "NumberingID": { "value": "POORDER" },

      "NumberingSeq": { "value": 10262 },

      "LastNumber": { "value": "V200000" }

    }

  ]

}

Translate

Steve Milner
Varsity III
Forum|alt.badge.img+6

@ashleyb Your body has the same shape as the one that updated only row 7 for me, so that error points at the endpoint. I got the exact same "More than one entity satisfies the condition." after I mapped two sequence fields (Last Number and Numbering Seq) on the Numbering entity itself instead of only inside the detail. With that in place, every GET and PUT for the record failed the same way, so a plain GET of POORDER on your endpoint will tell you if it's the same thing.

The fix is on Web Service Endpoints (SM207060). Open your endpoint, select the top-level Numbering entity, and check the Mapped Object column on the Fields tab. Delete any row that says Numbering Sequence Details, then save. Those fields belong on the detail entity only.

Once the PUT goes through, Last Number has to keep row 7's format and fall inside its Start Number to End Number range, or the save is rejected. It also only changes the next number that branch gets. It won't make the branch manual, so option 3 still means the customization @anahizentella94 described.

Translate

Forum|alt.badge.img
  • Author
  • Varsity I
  • October 22, 2026

Hi ​@Steve Milner that worked!! It looks like we had a field from the detail on the summary which was causing it to break. Thanks so much for your assistance! 

Translate