How to Build and Maintain Good Business Credit

A great business plan can get your foot in the door, but it will rarely get you a loan. As America struggles through one of the worst recessions in history, lenders are facing tighter restrictions, which means they're increasingly cautious about which businesses they're lending to. Good credit has always been an important facet of the overall health of your business, but experts agree that now is the time to beef up more than just your credit score and take a deep look at how you can improve your business in the eyes of lenders.

"The thing that's hitting us right now is the conditions of the marketplace," says Denise Beeson, a commercial loan officer with Bay Sierra Financial based in Santa Rosa, California. Beeson explains that banks are sitting on very toxic portfolios, and the only firms that are receiving funding are high-end sterling borrowers; in other words, businesses that exhibit a proven history of repaying their loans and posting profits.

Building and Maintaining Good Business Credit: Why It's Important

Good business credit provides access to capital, which is more important than ever, says Jeff Allen, a partner at Trendant, a small business consulting firm based in Utah. "What we've seen with a lot of small business owners is that they have really good months and they'll have an influx of orders, and they'll be able to fulfill them, but the next month or the month after that, they're back down to what they were," meaning that the orders stop flowing and the businesses need cash to sustain their operating costs. It's not uncommon that small businesses face this kind of down time, Allen says, and with good credit small businesses can weather these types of marketplace uncertainties.

Building and Maintaining Good Business Credit: The 5 C's of Good Credit

The crucial elements of borrowing money from a bank can be grouped into five categories known as the "Five C's," which is the ultimate credit checklist for any entrepreneur or small business owner.

"The five C's are very important," says John Seelinger, a California-based volunteer at SCORE, a non-profit organization dedicated to assisting entrepreneurs and small business onwenrs. "You can't afford to be sloppy or haphazard with them. The underwriting process may be different, but the fundamental five C's are always there," he says.

Capacity

Capacity refers to your ability – as a business – to repay the debt to the bank in a timely fashion. More than anything, a bank will look at your businesses' financial history to determine whether or not they will grant you a loan, so it's important to make sure that your company history has a pristine repayment record.

"Historicals is really important," says Allen. "Everyone comes up with projections, but actual historical information that can be verified is one of the most important things you can have. Without your historical information to back up your ability, you just have a 'plan.'" The bank will also assess how much debt you can really handle, and if the loan you're requesting makes sense given your cash flow.

Character

Banks want to be sure that they are lending money to reputable and trustworthy businesses. They're also looking to see that you're an expert in the industry your business operates in. Your character – both as a principle of the firm and the reputation of the business itself – should not be underestimated when approaching a bank for funding.

"You may see this as kind of inconsequential, but the quality of your references and the background and experience that you have to bring is critical," says Beeson. Plenty of people who have a great portfolio get turned down for a loan because they do not have any personal experience in that business.

Banks will also look at your personal credit, so maintaining a strong personal credit score is imperative. "A lot of what people do in their personal life goes directly into what they do in their business life," says Allen. "If they have a history of running up credit cards on a personal level, they'll probably fall into the same habit in a business." Remember, a bank will take a 360 view of your personal financial history, so before applying for a loan make sure you've settled any personal debts that could negatively affect a chance to obtain a loan for your business.

Capital

If you haven't invested in your business, why should a bank? A bank will scrutinize the financial investments that you and your co-founders have made because it's a good indication of your vested interest in the venture.

"Often times a small business owner who is just starting out will go to a bank and ask for a small business loan, says Beeson. "The bank is not going to lend them any money if they have no personal investment in their business." Essentially, banks want to see a track record that shows your dedication to your business, and a history of success within that field.

Collateral

Historically, collateral is the most important criterium in order to obtain a loan and establish a good credit line. "The key is collateral," says Allen. Collateral can be anything from real estate to equipment, and even purchase orders. If a business has an order that comes in, Allen says, "a bank will lend on that all day and night, because that's an order you can fulfill and then pay back."

Used equipment, an old truck, and other unsubstantial items that would not generate any substantial money for the bank are not going to be considered by the bank. "They're going to want to look for real property, and often times it's your home that they look for," says Beeson. "And with the real estate market as soft as it is, much of that real estate collateral is gone in equity. Unless there is a 401(k) plan or a stock portfolio or some collateral assets that are real, the bank isn't going to fund you."

Conditions

The bank will want to know what you will be using the money for, and what the current trends within your industry are. Beeson says that it's important to recognize that certain banks prefer to offer loans to certain industries, and so it's smart to target the banks that are most likely to view your loan favorably.

"I always tell people go to three banks like you would find a doctor," Beeson says. "Find a bank that wants to work with you and find out what it is you need to do. Prepare yourself for their criteria for a loan; it's not one size fits all." Overall, banks can be very choosy as to what their portfolio of loans looks like, so do your homework and find the best bank to suit your business's purposes.

Building and Maintaining Good Business Credit: Resources to Improve Your Credit

The first thing you can do to improve your credit is to make sure that all credit ranking companies, like Dun and Bradstreet, have the correct information about your firm. A wrong company name or a repaid debt that is not accounted for can ruin your chance of securing funding. Rectify any administrative mistakes before approaching a bank.

And, if you're having trouble securing a loan, or if you've been denied funding altogether, Beeson advises that you consider non-traditional financing routes, like peer-to-peer lending. Sites like Prosper and Kiva connect people who want to invest money with people who want to borrow money. And though you're not going to be able to finance a multi-million dollar business through these arrangements, they can get your business back on track.

http://www.inc.com/guides/2010/11/how-to-build-and-maintain-good-business-credit.html

Wrong PO Number

Welcome to another edition of my blog! This time around, I want to talk -- not literally -- about a common occurrence experimented in many Dynamics GP environments. When the pressure amounts, some company buyers may find themselves accidentally overriding the PO number field, a common misshap that may cause wasted time or the need to void and re-enter the document. Now, think for an instance, if you are using the Manufacturing module or any third-party product how cumbersome the task can become.

Fortunately, there is help on the way! I have developed a script based on a previous post, that will scan for the PONUMBER field in all tables in the company database. The script will automatically produce another script in the Results pane that can be copied and pasted into a new Query window and be executed against the company database.

The following example shows the script with the new PO number (@newponumber) and the old PO number (@oldponumber) variables being used to facilitate the interfacing with the person executing the change.

DECLARE @newponumber char(25), @oldponumber char(25)
SET @newponumber = 'PO1023'
SET @oldponumber = 'PO1001'

SELECT DISTINCT 'UPDATE ' + RTRIM(objs.name) + ' SET PONUMBER = ''' + RTRIM(@newponumber) + ''' WHERE PONUMBER = ''' + RTRIM(@oldponumber) + ''''
FROM syscolumns cols
INNER JOIN sysobjects objs ON (cols.id = objs.id)
INNER JOIN sysindexes indx on (cols.id = indx.id)
WHERE (cols.name = 'PONUMBER') and (objs.xtype = 'U') and (indx.rowcnt <> 0)


When this script is executed against plain vanilla GP v10, it produces the following results:
UPDATE POP10100 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP10110 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP10310 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP10500 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP30100 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP30110 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP30310 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE POP40100 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
UPDATE SOP60100 SET PONUMBER = 'PO1023' WHERE PONUMBER = 'PO1001'
(9 row(s) affected)

http://dynamicsgpblogster.blogspot.com/2008/04/wrong-po-number.html

GL Reconciliation SQL Script – Payables

This script can be used as a base to reconcile the receivables sub-ledger balances as of a certain date.

DECLARE @ASOFDATE AS DATETIME
 SET @ASOFDATE = '2017-04-12'
 SELECT  Z.*FROM    ( SELECT    A.[OPENYEAR] TRXYEAR,
                    A.[ORTRXSRC] AS ARAUDITTRAIL,
                    A.[ORMSTRID] AS ARCUSTOMERNO,
                    A.[ORCTRNUM] AS ARDOCUMENTNO,
                    A.[ORTRXTYP] AS ARDOCUMENTTYPE,
                    A.[TRXDATE] AS TRANSACTIONDATE,
                    RTRIM(B.[ACTNUMST]) AS GPACCOUNTNO,
                    SUM([DEBITAMT] - [CRDTAMNT]) AS GLAMOUNT
          FROM      [dbo].[GL20000] A
                    INNER JOIN GL00105 B ON A.[ACTINDX] = B.[ACTINDX]
          WHERE     A.[ACTINDX] IN ( SELECT [PMAPINDX]
                                     FROM   [dbo].[PM00200] )
          GROUP BY  A.[OPENYEAR],
                    A.[ORTRXSRC],
                    A.[ORMSTRID],
                    A.[ORCTRNUM],
                    A.[ORTRXTYP],
                    A.[TRXDATE],
                    B.[ACTNUMST]
          UNION
          SELECT    A.[HSTYEAR] TRXYEAR,
                    A.[ORTRXSRC] AS ARAUDITTRAIL,
                    A.[ORMSTRID] AS ARCUSTOMERNO,
                    A.[ORCTRNUM] AS ARDOCUMENTNO,
                    A.[ORTRXTYP] AS ARDOCUMENTTYPE,
                    A.[TRXDATE] AS TRANSACTIONDATE,
                    RTRIM(B.[ACTNUMST]) AS GPACCOUNTNO,
                    SUM([DEBITAMT] - [CRDTAMNT]) AS GLAMOUNT
          FROM      [dbo].[GL30000] A
                    INNER JOIN GL00105 B ON A.[ACTINDX] = B.[ACTINDX]
          WHERE     A.[ACTINDX] IN ( SELECT [PMAPINDX]
                                     FROM   [dbo].[PM00200] )
          GROUP BY  A.[HSTYEAR],
                    A.[ORTRXSRC],
                    A.[ORMSTRID],
                    A.[ORCTRNUM],
                    A.[ORTRXTYP],
                    A.[TRXDATE],
                    B.[ACTNUMST]
        ) ZWHERE   Z.[TRANSACTIONDATE] <= @ASOFDATE

http://cvakumar.com/msdynamics/2010/11/07/gl-reconciliation-sql-script-payables/

Posting Levels in Dynamics GP – A Review

I have been getting questions from many of my clients and network on the various levels of postings to the General Ledger accounts that are available in Dynamics GP. Hence I decided to provide some information on the same to all the folks in this community.

The level of posting to the GL accounts is determined from couple of setups working hand in hand in Dynamics GP which I will elaborate below. The initial setup is to define the level of postings for various accounts in the Account Maintenance window from Cards >> Financials >> Accounts as illustrated below.

We can specify the levels of posting from the various series into the General Ledger module. The various options available for posting levels are

• Detail
• Summary

Once this has been setup, we need to define the level of posting for various transactions in various modules in the Posting Setup window from Microsoft Dynamics GP >> Tools >> Setup >> Posting >> Posting as illustrated below.

So for the purpose of this case study, I created a couple of receivable invoices with the distributions explained below and saved them into a batch called RECVINV.

Invoice #1

Invoice Number	Account Number	Type	Debit (DR)	Credit (CR)
INV0001	000-1200-00	RECV	$500	-
INV0001	000-4100-00	SALES	-	$500

Invoice #2

Invoice Number	Account Number	Type	Debit (DR)	Credit (CR)
INV0001	000-1200-00	RECV	$700	-
INV0001	000-4100-00	SALES	-	$700

And I have setup the account 000-1200-00 to post at a Summary Level in the Sales Series in the Account Maintenance window, whereas I have setup the account 000-4100-00 to post in detail in the Sales Series in the Account Maintenance window.

Now, in the Posting Setup window, if we select the option to create one journal entry per transaction, posting will always be done at a detailed level (irrespective of the setting specified in the Account Maintenance window) (i.e.) There will be a one-to-one match between the distribution lines in the journal entry and the distribution that we had noted in the transaction posted in the sub ledgers.

So when the above batch RECVINV is posted in the Receivables module, there will be 2 journal entries created with the distributions explained below.

Journal Entry #1

Journal Entry	Account Number	Debit (DR)	Credit (CR)
12345	000-1200-00	$500	-
12345	000-4100-00	-	$500

Journal Entry #2

Journal Entry	Account Number	Debit (DR)	Credit (CR)
12346	000-1200-00	$700	-
12346	000-4100-00	-	$700

However in the above window, if we specify the option to create a journal entry per batch, we have two levels of roll ups that are available when journal entries are created when the sub ledger transactions are posted.

If the “Use Account Settings” option is unchecked, then when a batch of transactions is posted from the sub ledger module, the system creates one journal entry for all transactions posted in the sub ledger batch. However, there is no roll-up done at the account level, even though the accounts have been setup to post at summary level in the Account Maintenance window.

So in the same case study example above, if the batch was posted in the Receivables module, there will be one journal entry created with the distributions illustrated below.

Journal Entry #1

Journal Entry	Account Number	Debit (DR)	Credit (CR)
12345	000-1200-00	$500	-
12345	000-4100-00	-	$500
12345	000-1200-00	$700	-
12345	000-4100-00	-	$700

If the “Use Account Settings” option is checked, then when a batch of transactions is posted from the sub ledger module, the system creates one journal entry for all transactions posted in the sub ledger batch and the distribution amounts are rolled based on the posting levels for the accounts that are defined in the Account Maintenance window.

So in the same case study example above, if the batch was posted in the Receivables module, there will be one journal entry created with the distributions illustrated below.

Journal Entry #1

Journal Entry	Account Number	Debit (DR)	Credit (CR)
12345	000-1200-00	$1200	-
12345	000-4100-00	-	$500
12345	000-4100-00	-	$700

Note: Keep in mind that the various levels of postings will also be in effect only when we perform a batch posting in the sub ledger. If the posting is done at a transaction level, the system will always post in detail to the General Ledger (irrespective if the settings in the Account Maintenance window and the Posting Setup window for the specific sub ledger transaction).

Hope this article provides some insight into the General Ledger posting levels that are available in Dynamics GP.

http://cvakumar.com/msdynamics/2010/05/16/posting-levels-in-dynamics-gp-a-review/

Maintaining Data Integrity between Sub Ledgers and General Ledger

I have been involved in the process of reconciliation between the sub ledgers and the general ledger at various clients and there has been various scenarios in which there has been a break between the sub ledgers and the general ledger balances. A few key scenarios are quoted below

1. A transaction posted in the sub ledgers do not have a corresponding transaction in the general ledger.
2. A transaction posted in the sub ledger is backed out/corrected at the general ledger level.
3. Manual posting to the sub ledger control accounts in the General Ledger.

In this article, I am going to provide some tips to avoid any of the above situations and ensure that there is data integrity between the sub ledgers and the general ledger. This will ensure that the periodic audits done in the system proceeds in a smooth manner to a great extent.

The first two errors listed above can be prevented by disabling the following options in the General Ledger setup window from Microsoft Dynamics GP >> Tools >> Setup >> Financials >> General Ledger.

By unmarking the option “Deletion of Saved Transactions”, a journal entry batch that is created when a sub ledger transaction is posted, cannot be deleted at the General Ledger level. This prevents any deletion of a journal entry that was created from a sub ledger transaction. Note that if we have enabled “Post Through General Ledger” in the posting setup, this would not make a big difference, since whenever a transaction is posted in the sub ledger, the corresponding general ledger transactions get automatically posted as well.

By unmarking the option “Voiding/Correcting of Subsidiary Transactions”, the system will not allow us to void a journal entry batch that is created when a sub ledger transaction is posted. This prevents any voiding of a journal entry that was created from a sub ledger transaction. that if we have enabled “Post Through General Ledger” in the posting setup, this would not make a big difference, since whenever a transaction is posted in the sub ledger, the corresponding general ledger transactions get automatically posted as well. Further, this option will not allow the user to back-out (or) back-out and correct a journal entry that was posted for a sub ledger transaction.

The third error listed above can be eliminated by disallowing account entry for all the sub ledger control accounts like the GL accounts for Accounts Receivable, Accounts Payable and Inventory accounts, in the Account Maintenance window from Cards >> Financial >> Accounts, as shown below. We need to unmark the option “Allow Account Entry” for all the control accounts needed.

Unmarking this option for the key control accounts, will prevent the user from picking up this account in any transaction entry windows and will prompt the message as shown below.

This option will prevent any direct posting into the sub ledger control accounts in the General Ledger. All postings will happen only from the sub ledger module.

These options mentioned above are some key setups that we can enable in GP to minimize the data integrity issues between the sub ledgers and the general ledger which consumes precious reconciliation time which is spent by many resources during the key audit time.

http://cvakumar.com/msdynamics/2010/05/16/maintaining-data-integrity-between-sub-ledgers-and-general-ledger/

Sales Tax Simplified

It seems like the Dynamics GP forums are alive with sales tax questions lately. So, I thought I might tackle this one in the same manner that I do in the classroom-- by breaking it down in to steps. I treat sales tax as a three step process.

1. Document Default
2. Item or Setup Default (depending on if you are working with Receivables or Sales Order Processing, for example)
3. Tax schedule comparison

So, for this post, we are going to keep it simple and look at taxes in Receivables Management and Payables Management. I promise another post on Sales Order Processing and Purchase Order Processing next week :) But, for now, lets keep it simple.

Let's start with Step 1. There is one key setup that can impact the tax schedule that appears on a document (whether it be Payables or Receivables) by default. In your company setup, Tools>>Setup>>Company>>Company>>Options, there is a setting to Use Shipping Method to Determine Default Tax Schedule.

• If this option is marked, then the tax schedule that appears on the transaction will be dependent on whether the shipping method is a pickup or delivery method (more on this later).
• If this option is unmarked, then the tax schedule that defaults on the transaction will always be the Vendor Address' schedule (on Payables) or the Customer Address' schedule (for Receivables)

Now, let's look at Step 2. Now, Step 2 assumes that in your setup you have chosen Advanced for your tax calculations (Tools>>Setup>>Purchasing/Sales>>Payables/Receivables>>Options) rather than Single Schedule. Single schedule will always charge according to Vendor or Customer Address' schedule without Step 2 or Step 3.

In Step 2, we need to find the setup schedule (in Payables or Receivables). This is the schedule specified for each amount (Purchases, Sales, Freight, Misc, etc) in the setup options window mentioned above. In most examples in training manuals, these schedules are setup to include ALL DETAILS.

So, in Step 3, the schedule from the document (Step 1) is compared to the schedule from setup (Step 2). Details that the two schedules are compared, and only those that exist in both places are calculated.

Easy right? I know, I know..you are probably saying, huh? So, lets look at an example. Let's say that I have the following tax schedules set up:

• MOTAX: Contains the MOSTATE, KCCITY, MOSPEC, and JCKCTY Details which will be assigned to my Missouri based customers
• KSTAX: Contains the KSSTATE and KCKCITY Details which will be assigned to my Kansas based customers
• VALID: Contains the MOSTATE, KCCITY, JCKCTY, KSSTATE, KCKCITY which contains all of the currently valid tax details. I have purposely left off MOSPEC, it was a special tax that was only charged last year in MO and is no longer valid.

I set up my customer ABC AUTO with the tax schedule MOTAX, and I assign KSTAX as the default tax schedule for sales in Company Setup. VALID is specified in my Receivables Management Setup as the tax schedule for Sales.

Let's assume that we have chosen to have shipping method determine default tax schedule. So if I enter a Receivables invoice for ABC AUTO, the tax schedule will default as follows:

• Shipping Method with a delivery type: MOTAX (from Customer Address)
• Shipping Method with a pickup type: KSTAX (from Company Setup)

So, lets assume I use a Shipping Method with a delivery type, so MOTAX defaults. This would then be compared to the VALID tax schedule specified in setup. What is in common?

• MOSTATE, KCCITY, JCKCTY are the only taxes that would be calculated, since MOSPEC did not exist in the tax schedule in Receivables Management setup for comparison

I think of the tax schedule specified in setup as my "control" schedule, containing all valid tax details to be used in comparison against the documents. In many cases, this would be all details. But in some cases, as outlined above, it may be easier to remove a tax detail from the one control/setup schedule than to remove it from all schedules that contain it. This is also a great approach if a tax is only valid (or invalid) for certain portions of the year (think of sales tax holidays).

Please post back your questions or comments or examples to help with the understanding. I promise more next week on distribution. Have a great weekend!

PART TWO

Okay, okay, okay, please feel free to give me a very hard time for the delay in posting part two in our compelling sales tax saga. Last time, we worked through the basics of defaulting and comparing tax schedules for receivables and payables transactions. So, now we can move on to Sales Order Processing and Purchase Order Processing, where inventory items can impact the taxes that are calculated. The examples that follow assume that you have marked to use shipping method to determine default tax schedule in your company setup (as discussed in our previous post). Again, let's look at taxes as a three step process.

1. Document Default
2. Line Item Default
3. Tax Schedule Comparison

So, step one works pretty much the same as it did in our earlier post. However, we need to take it a step further by considering the inventory site, like the following examples (assuming you are registered for inventory) in Sales Order Processing:

• Shipping Method Delivery: Default tax schedule assigned to Customer's Ship To Address
• Shipping Method Pickup: Default tax schedule assigned to the Site

Now, although I call this a "document" default, because Shipping Method and Site can vary by line item in Sales Order Processing and Purchase Order Processing, this default actually is stored by line item.

So, what about Step 2? Well Step 2 takes in to consideration the inventory item card (or the Sales Order/Purchase Order Setup when dealing with non-inventory items). There are three possible settings for inventory items for Sales and Purchase taxes:

• Nontaxable: No tax is ever charged for this item
• Base on Customer/Vendor: This will charge according to the shipping method
• Taxable: Specify a tax schedule that represents all possible tax details to be charged on this item, more on this later...

So, let's work through a couple examples. First, let's look at the Base on Customer setting. Let's assume that we have entered an invoice for our customer ABC AUTO. They want all items to be shipped to them (Shipping Method- Delivery) at their Missouri location which is assigned to the tax schedule MOTAX which includes the MOCITY and MOSTATE tax details.

Let's say that ABC AUTO buys two items from us, the first item is a gift basket, BASKETOFUN. BASKETOFUN is set with the sales tax option of Base on Customer. So what does that do? If we were to click the item number expansion arrow for this line in Sales Transaction Entry, we would see the following information being stored in the Sales Item Detail Entry window:

• Shipping Method: Delivery
• Ship To Tax Schedule: MOTAX
• Item Tax Option: Base on Customer
• Item Tax Schedule: n/a

Therefore, in this example, all details in MOTAX would be calculated. Now, let's shake it up and say that this particular line item changed to a Shipping Method of Pickup. Let's say that this line item is being sold from our NORTH site with the tax schedule NYTAX. We would then see the following in the Sales Item Detail Entry window:

• Shipping Method: Pickup
• Site Tax Schedule: NYTAX
• Item Tax Option: Base on Customer
• Item Tax Schedule: n/a

So, in this scenario, what taxes would be calculated? All details in the NYTAX schedule would be calculated. Sometimes this scenario is confusing to users, because the item is set to Base on Customers. But what that really means is that the item's taxability is based on the Shipping Method itself, and how the tax schedule defaults.

But, wait, I said that we sold two items right? So let's look at the next item that ABC AUTO bought. They bought our new virtual gift basket, VIRTUALBASKET. Now, some states tax the virtual gift basket, and others do not. So we have set up the VIRTUALBASKET with a sales tax option of Taxable. We have then assigned a special tax schedule to it called VIRTUAL, which includes the taxes that are calculated on virtual products. In our case, let's say that it includes the MOSTATE, KSSTATE, and COSTATE tax details.

If we look at the Sales Item Detail Entry, we would see:

• Shipping Method: Delivery
• Ship to Tax Schedule: MOTAX
• Item Tax Option: Taxable
• Item Tax Schedule: VIRTUAL

Which taxes would be calculated? Only those that are common between MOTAX and VIRTUAL, in this case the MOSTATE detail would be calculated.

But, let's mix it up and say that the customer has asked that this item be shipped to their California location which is assigned to the CATAX schedule (which includes the CASTATE and CACITY tax details). So, let's look a the Sales Item Detail Entry again with these details:

• Shipping Method: Delivery
• Ship to Tax Schedule: CATAX
• Item Tax Option: Taxable
• Item Tax Schedule: VIRTUAL

Which taxes would be calculated in this scenario? None, because the CATAX schedule does not have any details in common with VIRTUAL. This is correct, since we said that our item was only taxable by Missouri (MOSTATE), Kansas (KSSTATE), and Colorado (COSTATE) not by California.

So, the Taxable option for items creates the most flexibility when you have items that are taxed in some states and other items taxed in all states (or different states). I have found this comes in to play quite often with technology products, including software downloads, where some states are more aggressive in taxing these items than others.

Clear as mud? Share you questions, hints, etc and I am happy to update the post--from Alaska, where I am this week teaching :)

"End of Month + Net Days" payment terms due date calculation

Folks across the pond use payment terms and due dates that are not traditionally close the ones we are familiar with on this side of the hemisphere. "End of Month + Net Days" (EOM+ND) is a typical case.

In EOM+ND payment terms, an invoice becomes due a number of net days after the last day of the month for the invoice date. For example, if an invoice date is July 16 and we are on a payment term of EOM plus 45 net days, the invoice will not be due until September 14 -- or 45 days from July 31.

Of course, you cannot manage this type of payment term request in GP, not out-of-the-box anyways, which most of the time will require a customization to deal with the issue.

In this article, I will examine setting up two SQL Server triggers: one on the PM Transaction Open File (dbo.PM20000) and another on the RM Open File (dbo.RM20101) tables. The triggers will use the Net Days field in the Payment Terms Master (dbo.SY03300) table to calculate the net days after the end of month to assign the invoice due date.

So here are the triggers:

trigger pmEOMPlusNet

-- Created by Mariano Gomez, MVP
-- No warranties expressed or implied
CREATE TRIGGER pmEOMPlusNet ON dbo.PM20000 AFTER INSERT
AS
BEGIN TRANSACTION;

BEGIN TRY
  UPDATE A SET A.DUEDATE =
    DATEADD(dd, B.DUEDTDS, DATEADD(dd, -1, DATEADD(mm, DATEDIFF(mm, 0, I.DOCDATE) + 1, 0)))
  FROM PM20000 A
    INNER JOIN INSERTED I ON (A.VCHRNMBR = I.VCHRNMBR) AND (A.DOCTYPE = I.DOCTYPE)
    LEFT OUTER JOIN SY03300 B ON (I.PYMTRMID = B.PYMTRMID)
  WHERE (I.DOCTYPE = 1) AND (I.PYMTRMID LIKE 'EOMPLUSND%')
END TRY
BEGIN CATCH
  SELECT ERROR_NUMBER() AS ErrorNumber
    , ERROR_SEVERITY() AS ErrorSeverity
    , ERROR_STATE() AS ErrorState
    , ERROR_PROCEDURE() AS ErrorProcedure
    , ERROR_LINE() AS ErrorLine
    , ERROR_MESSAGE() AS ErrorMessage;

  IF @@TRANCOUNT > 0
    ROLLBACK TRANSACTION;
END CATCH;

IF @@TRANCOUNT > 0
  COMMIT TRANSACTION;
GO

trigger rmEOMPlusNet

-- Created by Mariano Gomez, MVP
-- No warranties expressed or implied
CREATE TRIGGER rmEOMPlusNet ON dbo.RM20101 AFTER INSERT
AS
BEGIN TRANSACTION;

BEGIN TRY
  UPDATE A SET A.DUEDATE =
    DATEADD(dd, B.DUEDTDS, DATEADD(dd, -1, DATEADD(mm, DATEDIFF(mm, 0, I.DOCDATE) + 1, 0)))
  FROM RM20101 A
    INNER JOIN INSERTED I ON (A.CUSTNMBR = I.CUSTNMBR) AND (A.DOCNUMBR = I.DOCNUMBR)
      AND (A.RMDTYPAL = I.RMDTYPAL)
    LEFT OUTER JOIN SY03300 B ON (I.PYMTRMID = B.PYMTRMID)
  WHERE (I.RMDTYPAL= 1) AND (I.PYMTRMID LIKE 'EOMPLUSND%')
END TRY
BEGIN CATCH
  SELECT ERROR_NUMBER() AS ErrorNumber
    , ERROR_SEVERITY() AS ErrorSeverity
    , ERROR_STATE() AS ErrorState
    , ERROR_PROCEDURE() AS ErrorProcedure
    , ERROR_LINE() AS ErrorLine
    , ERROR_MESSAGE() AS ErrorMessage;

  IF @@TRANCOUNT > 0
    ROLLBACK TRANSACTION;
END CATCH;

IF @@TRANCOUNT > 0
  COMMIT TRANSACTION;
GO

Setting up the payment term in Dynamics GP

Open the Payment Terms Setup window (MSDGP > Tools > Setup > Company > Payment Terms) and configure the payment term as shown below:


NOTE: You can still setup discount and discount types for the payment term, but these will be calculated based on the document date. If you need these to apply based on EOM as well, you will need to change the above triggers to reflect the discount calculation based on EOM as well.

Finally, once setup, these payment terms can be used from SOP and POP. Just keep in mind that the due dates will not be calculated while the transactions are stored in a batch, but rather when posted.