Wednesday, November 11, 2009

Moving from Work to Open to History

This article started from a question posted on the newsgroup. There doesn't seem to be any summary of how transactions move from Work to Open to History.

I put together this document attempting to address this for the following series:

  • GL
  • CM (Bank Transactions)
  • AR
  • AP
  • SOP
  • POP
  • Invoicing
  • Inventory
I haven't worked on Payroll yet.

GL

Work - Unposted GL Transactions
Open - Posted GL Transactions
History - When GL Fiscal Year Closes


Until the year closes all of the GL transactions are in the Year to Date Transaction Open table. You cannot move them back to the Open table after the year end closes. Entries cannot be ‘unposted’ and moved back into the Work table.

CM (Bank Transactions)

Work – Unposted Deposit Transactions
Open – Posted Bank Transactions
Posted Deposit Transactions
Reconciliations
History – There is no history table

AP

Work – Unposted AP Transactions
Open – Posted AP Transactions that are not yet fully applied.
Posted Purchasing Invoices that are not yet fully applied.
History – Transactions automatically move to history when the document is fully applied (a transaction is a check, credit memo, invoice, etc.) For a check or credit memo it is when the amount is fully applied to an invoice or invoices. For an invoice it is when it is fully paid off, or a credit memo, or memos takes the balance to zero. Voiding a document in the Open file moves it to history. Documents can be voided after they have been moved to history and that moves them back to the Open table. Documents cannot be 'unposted'.

AR

Work - Unposted
Open - Posted AR Transactions
Posted SOP Invoices
Posted SOP Cash Receipts
History - You need to run the 'Paid Transaction Removal' routine in order to move transactions to History. Nothing automatically moves to history. This routine will only move 'fully applied' documents to history. So if you still have a balance on an invoice it stays in the Open Table. If a credit memo or receipt has not been applied to an invoice, it will stay in the Open table. The fact that the customer's net balance is zero does not impact whether the document moves to history.


When you run the Paid Trx Removal you specify a cutoff date that applies to
NSF checks
Voided documents
Waived (finance charges)
Paid Transactions

You specify a separate date for:
Checks

Once AR transactions are moved to history - they cannot be voided thereby moving them back to open. This is why the checks have a separate date - what if they bounce!



Documents can be 'unapplied' only while they are in the Open file, not after they have been moved to history. For instance, if you applied a cash receipt to the wrong invoice, you can change it to the correct invoice only if it has not been moved to history.



Documents can be voided only while they are in the Open file.

SOP

Work - Unposted documents
Open - There is no Open file (when SOP docs are posted the transactions go into the AR Open file)
History -These transactions automatically move to history:
Posted SOP Invoices or SOP Returns
Voided SOP Documents
Orders whose items have been fully transferred to other documents
Quotes that have had any item transferred to another document
Backorders that have been fully transferred to other documents
For documents that do not automatically transfer to history, run the Reconcile-Remove Sales Documents utility.

The following documents cannot be posted
Quotes
Orders
Backorders

POP

Work - Any document that has not been moved to history
Open - There is no open file
History
Posted Receipts automatically move to history
Posted Purchasing Invoices automatically move to history
Voided Purchasing Documents automatically move to history
Purchase Orders - You must run the Purchasing Routine 'Remove Completed Purchase Orders'. This will move all of the closed or canceled POs to History. If a PO is not closed or canceled it will not be moved, so there is no danger of moving a PO that doesn't qualify. You can set restrictions on which POP docs are examined for removal.

IVC (Invoicing)

Work – Unposted Documents
Open - There is no open file (posted transactions update receivables, like SOP)
History
Posted Invoices automatically move to history
Posted Returns automatically move to history


IV (Inventory)

Work – Unposted Adjustments
Unposted Variances
Unposted Stock Counts
Unposted Transfers
Open - There is no open file
History – Posted Transactions




Friday, November 6, 2009

Database Maintenance Utility

After you load GP 10 you will notice a little extra item has loaded. That extra item is called the Database Mantenance Utility. I've been asked many times of late as to what it does and why we should care. Here goes. When the databases are created by GP several other objects are created as well. Views, Triggers, Stored Procedures and functions. Sometimes these objects become corrupted or messed up in some other way and need to be reloaded. The Database Maintenance Utility is the tool for the job. Before running this utility please be sure to back up your database. Also script out any customizations you have made to any of these objects, because they will need to be reapplied.

As an aside, you want to script any changes made to table keys and indexes because you will most likely need to re-run those modifications after any table update.

That's all for now, I'm heading to the Tech Conference Friday.

Hope to see you there!

Using the Adjust Costs inventory Utility Warning!

Adjust Costs.

It looks like a simple enough tool and it does exactly what you tell it to do. However, read on, what it does may not be exactly what you want it to do. Here's what it does. Say you have a purchase receipt that went through the system at $1465. Several of the items were sold but now the inventory is obsolete and the powers that be task you to write it off. They still want the items in inventory in case they can sell them later, but the carrying value should be zero. No Prob! you say. You open up the adjust cost screen and take each of the receipts that have not been completely sod and adjust the cost to zero. A bunch of reports print, you check that your stock status shows zero and you think you are done.

Not so fast. When you make a cost adjustment to a receipt in the Adjust Cost window you are telling the system that the entire receipt had a bad cost, not just the items left over. Dynamics GP will go back and attempt to adjust the cost on the posted sales from this receipt to the new cost (in our case $0). You may not want that. If all you are trying to do is write the current inventory down to zero cost, make Inventory Transaction Entries. First, a negative entry which will pull the correct cost. This will give you your 'write off' journal entry. Next do an increase adjustment at $0.00 cost. Now you have written off exactly the inventory you want and the carrying value is zero.

You can go home fulfilled from a good writeoff :)

UPDATE! I read a post on the GP Forum the other day that was posted by fellow MVP Mahmoud M. AlSaadi  where he provided an excellent explanation of how the Adjust Cost Utility worked. I've modified the post only slightly, but this is what it told us.
The Inventory Adjust Cost Utility primarily does the following;
· Update the (UNITCOST) field  in IV10200 | Inventory Purchase Receipts Work. (The old Unit Cost will be reserved under ADJUNITCOST field ) 
· Since the purchase receipt within the IV10200 is linked to the Inventory Purchase Receipts Detail, these cost layers will be updated accordingly.
· A new Cost Adjustment Record is written to the HITB | Historical Inventory Trial Balance either to decrease or increase the cost.
· A Corresponding Journal Entry to adjust the Purchase Receipt Cost in General Ledger is created. That Journal Entry is linked to the cost adjustment record in the HITB
· No changes at all to the IV30300 | Transaction Amounts History
In summary, if you have received and invoiced the items, but the cost is not correct and needs to be adjusted, the best way is to correct this is to use the "Adjust Cost Utility". If the cost had been corrected through the Enter/Match invoice transaction, then the cost adjustment record and all of the corrections mentioned above would have been applied. However, if the invoice cost was not corrected at the time of invoicing, the Adjust Cost Utility is your answer for fixing it.

Until Next Post

Leslie

Friday, September 25, 2009

Dexterity Training in Orlando Oct 5 - 9, 2009

Come to Florida for Dexterity Training!

This class is only held once per year, so please don't miss it if you are interested in learning Dexterity.

If you want to sign up please call Roxanna at 407-677-0370 or ralvarez@ibgnet.com.

This is a hands-on programming class using Microsoft Dexterity. This class will take you from creating the initial development environment to delivering a fully integrated .cnk file.

This week-long Class will include several programming projects such as:
  • Creating a data-entry window project
  • Using the debugging tools
  • Creating a lookup window project
  • Understanding multi-user record locking
  • Creating a transaction entry project
  • Using Dexterity Utilities
  • Creating an integrating application project using object triggers
  • Creating integrating reports with Report Writer
For more information look here:
http://www.ibgnet.com/images/pdfs/Dexterity_I_Synopsis.pdf

To sign up for the class look here:
http://www.ibgnet.com/IBG-Training-GP.html

Wednesday, July 1, 2009

Copy Fields for Jocelyn

Here's what the Calculated Fields section looks like for the Direct Deposit Earnings Statement:
This to answer Jocelyn's question on Copying calculated fields.

CalculatedFields
{
CalculatedField "SickAvail"
{
EvaluateAfter ""
Expression " ( 'UPR_WORK_Check'.'Sick Time Available' - 'UPR_WORK_Check'.'Sick Time Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "VacAvail"
{
EvaluateAfter "SickAvail"
Expression " ( 'UPR_WORK_Check'.'Vacation Available' - 'UPR_WORK_Check'.'Vacation Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "Sick Time Total"
{
EvaluateAfter ""
Expression " ( 'UPR_WORK_Check'.'Sick Time Available' - 'UPR_WORK_Check'.'Sick Time Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "Vacation Time Total"
{
EvaluateAfter "Sick Time Total"
Expression " ( 'UPR_WORK_Check'.'Vacation Available' - 'UPR_WORK_Check'.'Vacation Hours' ) * 0.01000 "
ResultType "Currency"
}