When entering Vendor Invoices, we enter the Vendor Document Date based on the actual date printed on the Vendors Invoice. We do this so that the Due Date of the Invoice will be accurately calculated based on our terms with each Vendor. When we receive product we issue the Receipt immediately into POA. Later (sometimes a week or two) we receive the invoice. When we enter the Vendor Document date it is often prior to the Receipt date. For example the Receipt may have been entered on Sept 2 and the Invoice arrives on Sept 8 but is dated Aug 27. When we enter the Invoice on Sept 8 in POA we change the Vendor Document Date to Aug 27, which also changes the Document Date on the first screen to Aug 27, ultimately posting the Invoice into August. The Vendor terms (i.e. Net 30) are calculated correctly by doing this, however, it would be much better (in my humble opinion) if the Vendor Document Date was used only to determine the Due Date of the Invoice and not change the actual Document Date (posting date). The posting date should be the date it was posted (i.e. Sept 8).

It took me a long time to figure out why our Accounts Payable Clearing Account was showing a Negative amount on our Balance Sheet at the end of each month. That account should only be receipts that have been added to inventory but haven't been entered as Invoices yet. Accounts Payable Clearing Account should therefore always be a positive amount on the balance sheet and can be easily added to the Payable amount for a Payable total. Back dating our Invoices is skewing our month end numbers.

Is keeping the Vendor Document Date as "today" and overriding the terms and manually entering the true Due Date our best option? Or is there some way to disconnect the Vendor Document Date from changing our Posting Date?

Hi, Susan,

It sounds like what you're requesting is that we implement an Accounting Date in Purchase Orders, the way we have in Receivables 9.0A. I can certainly enter the suggestion to R&D for you.

Right now, if you want the date sent to GL from the invoice to be the posting date, you'll want to ensure the Vendor Document Date is that date and manually enter the true Due Date on the invoice as you suggested.

At present,

It's late after a LONG week so my mind may be a more than a little screwed, but if the clearing account is value of inventory received and invoice not posted to payables the clearing account should be a negative. Posting the invoice would debit the account and result in a credit to payables.

Or has the week really been that long?

David

I agree with David (not that his mind is little screwed but with his reasoning). The account SHOULD have a debit balance if most of the invoices pre-date the receipts, which is not all that unusual.

Steve

Timing issues exist to keep accounting from being boring all the time.

Gotta love it.

David

Since we are always in a state where we have received product onto our system that we have not been invoiced for, we should have a Credit balance most of the time that shows up in the Liabilities section of our Balance Sheet as a Positive amount.

Thanks Softrak support. We'll discontinue back dating our invoices and instead manually edit the due day to work around it until such time as Softrak separates the Vendor Document Date from the Accounting date in POA.

Softrak Support,

We have been using the workaround we talked about in this post:

POA/Totals/Invoice then delete the terms field to enable the discount and due date fields. Then manually enter the Discount date, Discount Percentage and Due date.

After posting these invoices, the Due date is showing up correctly in AP, however, the Discount date and Percentage are going into AP with no data (no date, no percentage).

Is there a way to have these fields post to AP correctly when they have been manually entered?

Hi Susan

This jogs my memory as a known issue. Ryan at Stief Group will know for sure. If so, it needs to be addressed with the next upgrade or service pack.

Steve

So a workaround for this workaround would be to edit the batch in AP before posting it? Any estimate on when a fix might be coming?

Ryan tested this and got the same results.