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
1 ABC
2 DEF
3 GHI
Now i have to merge LOCATION DEF In ABC with the new no series
eg On 01/04/14 i have entries
ABC DEF
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
DEF DEF
1 TI/DEF/0001 1 RI/DEF/0001
2 0002 0002
3 0003 .
.
.
RI/DEF/0007
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
00006
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.