No. Series Merging in Posted Sales Invoice

Dear User,

i have been assigned a work in which i have merge the no series of postes sales invoice on the base of location & posting date with the new no series.

suppose there are 3 location in location code of sales invoice header




Now i have to merge LOCATION DEF In ABC with the new no series

eg On 01/04/14 i have entries


TAX invoice entries Retail Invoice entries

1 TI/ABC/0001 1 RI/ABC/0001

2 TI/ABC/0002 2 RI/ABC/0002

3 0003 3 0003

4 0004


1 TI/DEF/0001 1 RI/DEF/0001

2 0002 0002

3 0003 .




Now after this when i run the processonly report the entries should changed to

01/04/14 date filter

Tax invoice entries

1 TI/ABC/00001

2 TI/ABC/00002

3 00003

4 00004

5 00005


7 TI/ABC/00007

Retail invoice entries

1 RI/ABC/00001

2 RI/ABC/00002





10 RI/ABC/00010

Hi Abuzar,

A high-level question here … are you trying to renumber posted documents? If so, my first thought would be to advise against it. That value is spread across so many different ledgers and you’d be obligated to change them all. The likelihood of missing some of them is pretty high.

Yea i know its pretty high level question but i have to do this work & also i’m unaware of batch jobs & process only reports,when i put the code coverage in posted sales invoice so i found out these tables in which entries get affected

G/L Entry

Tax Entry

Cust. Ledger Entry

Detailed Cust. Ledg. Entry

Value Entry

Detailed Tax Entry

The document numbers of posted transactions are not intended to be changed. Were I you, and I were being asked to undertake this action on the behalf of a client, I might look to secure a release of liability from the client before engaging in the work. Reason behind that position is that, at least so far as I know for US companies, the act of modifying the accounting ledgers through means outside of the standard UI commits an offense known as blowing the audit trail - a quite serious condition in accounting circles. While document numbers may not be significant to financial statements validity, it’s the act of directly modifying a ledger that brings them into question, not the nature of the modification. Should your client be subject to the US SOX regulations or other similar FTC requirements, your modifications could actually jeopardize their community standing. I personally would not undertake such an action without first securing a writing to the effect that the client would bear the full risk.

That notwithstanding, be sure to look in description fields in ledgers and sub-ledgers for references to the document number values you’re changing. Also take care that there would be no overlap between old numbers and new numbers; you wouldn’t want to change an old value to a new value, only to have the new value be considered old by subsequent code and changed yet again.