Currently, if an order is Closed, the customer number is not renumbered when doing a renumber. This is ludicrous. If you renumber all of the invoices (not just open), then why wouldn't you renumber all of the sales orders? If I wanted to know what they purchased before the renumber, I'd create a new customer number. What if a customer just changed their name? Why on earth wouldn't I want to know what they purchased before their name change?
And, of course, if you are doing a Crystal Report on the SO History file and link in the Customer file - zonk, all of those orders that weren't renumbered are toast.
by: Beth B. | over a year ago | Financial Management
Comments
In Sage's KB it doesn't list that the SO_SalesOrderHistoryHeader file is updated, so was that by design NOT to update the SO History Header record? Doesn't make sense to me at all.
Change Tab - The following files are updated if you change a customer number.
AR_Alternatelnvoice
AR_CashReceiptsDetail
AR_CashReceiptsHeader
AR_CashReceiptsHistory
AR_CashSales
AR_Customer
A R_C ustomerContact
AR_CustomerCreditCard
AR_CustomerCreditCardEBMUser
AR_CustomerMemo
AR_CustomerMemoSettings
AR_CustomerSalesH ¡story
AR_CustomerSalesperson History
AR_CustomerShipToTaxExemptions
AR_DailyPostingWork
AR_DepositHistory
AR_FinanceCharge
AR_lnvoiceHeader
AR_lnvoiceHistoryHeader
AR_Openlnvoice
AR_OpenlnvoiceSplitCommissions
AR_OpenlnvoiceTaxSummary
AR_RepetitivelnvoiceDetail
AR_RepetitivelnvoiceHeader
AR_RepetitivelnvoiceTaxDetail
AR_RepetitivelnvoiceTaxSummary
AR_SalespersonCommission
AR_SalesTax
AR_SummaryDr¡IIDownWork
AR_TransactionPaymentH ¡story
GL_SummaryDetailDr¡IIDown
IM_AI¡asltem
IM_Pr¡ce
IT_Customer
IT_Shopp¡ngCartAutoLogHdr
IT_Shopp¡ngCartHeader
IT_UIDCustomerChange
IT_UIDCustomerChangeAutoLog
JC_Job
JC_JobBilling Header
RA_Customerlnvo¡ceSearch
RA_GenerateTransact¡ons
RAJnquiryReceiptsHistoryLink
RA_ReceiptsHeader
RA_ReceiptsH¡storyHeader
RA_Repa¡rDeta¡l
RA_Return Header
RA_Return Reason Detail
SO_AutoGeneratelnvoices
SO_Da¡lyPostingWork
SO_Da¡lySh¡pment
SOJnvoiceHeader
SO_LastPurchaseH¡story
SO_LotSerial History
SO_SalesH¡story
SO_SalesOrderHeader
SO_SalesOrderRecap
SO_ShipTo Address
SO_SummaryDr¡IIDownWork
Wow, been a year. Do we dare hope that this made the v2022 release? IMHO, this is a critical oversight of HUGE proportions. I have a client that merges duplicate customer numbers on a monthly basis. Please don't call this a WAD and put it on the back burner. This is a flat out bug and needs to be fixed ASAP. Can't be that hard. Just duplicate the code from one of the many existing routines modify a table above.
And this BEGS the question, is this an issue in PO History when changing vendor numbers????
Sage, is this bug/oversight/poor programming slated for correction any time soon? It might make a difference as to whether I change any accounts or wait for the next release...
SAGE-THIS NEEDS TO BE FIXED. MAJOR OVERSIGHT causing daily headaches.