Recommended: Click here to improve PC speed »
Great Plains Receivables Management (or Accounts Receivables as a different name)module gets its transactions through direct module posts as well as from GP SalesOrder Processing Module. For Great Plains there is very popular data supportroutine, where you as GP developer or programmer have to fix failing batch postingor RM data transfer to history. In Microsoft Great Plains you can try severaltechniques, first would be Check Links, which may potentially fix or at least directyou on where the problem would be. Check Links is powerful technology, however itis in hands of GP Dexterity developers, who tried to think through various scenariosof data to become inconsistent, but you can expect the life to give you additionaldata inconsistency surprises. Let us give you orientation on SQL query design toupdate, fix or reconstruct failed data:1. GP RM Open Tables: RM20101 this is open transactions, plus this one RM20201 open apply to transactions table. Most of the RM posted transactions are repairedin these two tables, assuming that you are not moving Open transactions to thehistory on the weekly or monthly basis. If you, however move transactions to thehistory, the next paragraph orients you on the historical tables2. GP RM Historical Tables: RM30101 receivables management transactions historyand RM30201 apply to receivables transactions history file. Please be aware fromthe beginning that RM historical data fixing is a way more complex than the one foropen tables, due to the fact, that you can not void historical RM transactions in GPworkstation interface. All you really can is to remove historical transaction viaSQL scripting delete statement or update applied amount via update statement3. Check Links. For those who are not familiar with this routine, please in GPworkstation go to Microsoft Dynamics GP->Maintenance->Check Links, select Salesseries and include Receivables Open Transaction Files, plus for the historyReceivables Transaction History Files4. Avoiding Data Damaging. Before you do your surgery on the above mentionedtables, we recommend you to make table backup use the following script as anexamples: select * into RM20201_Backup from RM20201. The rollback script includesthese statements: alter table RM20201_Backup drop column dex_row_id and then you candelete specific records in RM20201 and insert them from backup table. Again SQLupdate statement is very powerful and you can easily destroy your ERP records withone click of the mouse
Andrew Karasev, Alba Spectrum Group, http://www.albaspectrum.comhe lp@albaspectrum.com 1-866-528-0577, 1-630-961-5918, serving Microsoft Dynamics GPUSA and Canada nationwide: Toronto, Montreal, Vancouver, Calgary, Windsor, New York,San Francisco, Los Angeles, Miami, Orlando, Pittsburg, Toledo, Indianapolis,Detroit, Philadelphia, Boston, Washington, Seattle, San Diego, Phoenix, Austin. Local service is available in Chicago and Houston metros: Rosenberg, Katy, Richmond,Dallas, Galveston, Sugar Land, Naperville, Wheaton, Plainfield, Aurora, Wheaton,Downers Grove, Lisle, Oakbrook, Morris, Marseilles, Joliet, Montgomery, Oswego,DeKalb. With reasonable travel we serve Springfield, Bloomington, Normal, Peoria,LaSalle, Ottawa, Dixon
