NEVER use Test in VI since it went to Framework. My suggestion is to go look at the GL and see if they are there.

The GL Main accounts are there, but when I go to the GL Accounts there are only two.

Louis - what is the reason you do not suggest using the Test function? I have never had a problem with it, and use it on EVERY import I run.

This has been discussed at the Sage Summit for the last few years. With the framework you should do all testing in a test company and click Accept and NOT Test because Test will not return true results and will create records whereas in the old legacy days Test would not create records.

Thank you to @BigLouie. I will follow your lead from now on; no more Test.

I know you've said this numerous times, BigLouie, but I've never experienced records being created when I used the Test button.  I do use the Test button when creating my VI in a test company to catch any preliminary errors (oh, I forgot that field was required!) and just to make sure my mapping is correct.  I've never seen it create records.  Are there specific tables or modules that have this issue more than others?  I find the Test button useful, but obviously want to avoid any issues.

It's nice to know I (and others I work with and spoke to this afternoon) are not the only ones to feel this way. I was taught this way and frankly, being a CT, I was very surprised by this post. I had NEVER heard that before - not in any of the training sessions, or meetings at Sage.

If we are not to use the button, why didn't they remove it? Why is this not written anywhere?

I'm not questioning you Louis - you know I would never do that, my questions are with Sage!!!

And for the record - most of us know the TEST function has never returned accurate results. But it has been a good tool for those of us who know how to use it :)

On any data  entry imports such as Sales Order, Invoice, Purchase Order it will create the record. If you want to test do an import of Sales Orders and click the Test button.  When finished go into SalesOrderQuoteHistory and look up one of the numbers. Note that the Sales Order is now listed in history as deleted. Also there are some features such as the Next function that will not appear to work in Test but will work in actual.

Also since you are a reseller I would suggest contacting Scott Brady with Sage who is the VI guru and should be able to help you get your GL import working.  His landmark session on VI at the old Derixons turned into a near riot and is still fondly remembered.

Here is an entry from the Knowledge Base of just one situation that happens when using the test button:

Subject:

A batch number is created in General Journal Entry after clicking the 'Test' button in Import Job Maintenance for GLJournalHeader Import job.

Steps to Duplicate:

Open GL / Setup / General Ledger Options.

Select the 'Entry' tab and click the 'Enable' checkbox for 'General Journal Entry'.

Open VI / Main / Import Job Maintenance.

Type a name for the job and select the 'GL_GeneralJournalHeader' table.

Verify that all required fields including 'H.BatchNo' are selected and have a valid operation.

Click 'Accept'.

Click 'Yes' to excute the job.

Click 'Test' to test the job.

Select the amount of records to test.

Open GL / Main / General Journal Entry.

Click on the Lookup button.

Note that a batch has been created.

Run the import job again.

Note that all the records fail with "This Entry Already Exists in Batch xxx". (xxx = batch number)

Possible Resolution:

Resolution 1: Delete the batch in General Journal Entry after running the 'Test', before running the final import.

Resolution 2: Reinitialize the following files:

Note: Use caution when working with this task. Always make a backup first. If necessary, seek the assistance of a qualified Sage Software support analyst.

GL_GeneralJouranlHeader

GL_GeneralJouranlDetail

GL_CompanyActiveBatch

Here is another:

Subject:

Invoice and batch numbers increment during testing phase if the Next operator is used for AR_InvoiceHeader jobs created in Visual Integrator. Invoice and batch numbers should not increment when testing import jobs. They should increment only during the actual import.

And a third:

Status:

For current information on this issue, please click the Engineering Status link above. To record the occurrence of this issue, respond Yes to the question, "Did this answer help you?"

Subject:

"L Record Invalid or Write Failed. The AP Invoice Number is required" when testing an import into AP_CheckHeader. When trying to import after this test an error is generated "The invoice XXXXXX is already paid" These issues do not occur when performing a straight import without testing

Steps to Duplicate:

In [ABC] company:

Create a VI import job for AP_Checkheader (a sample import can be found at \\tradewind\public\DRC\MAS 90\SWATT\Attach\Tools\4606551)

Create a sample source file matching the import job from step 1 (a sample source file can be found at \\tradewind\public\DRC\MAS 90\SWATT\Attach\Tools\4606551)

Test the import and notice that failed record

Accept the import to attempt an actual import and notice the second error "The invoice XXXXXX is already paid"

Expected Behavior:

It should be possible to test an import.

Possible Workaround:

One option is not to test the import

Another option is to reinitialize the AP_CheckHeader and AP_CheckDetail files

I got my import working, but thanks.

I love the Expected Behavior notation "It should be possible to test an import" If that is not the epitome of ineptness on the part of Sage, I don't know what is.......

Even Blytheco displays the ability to test VI jobs on their web site:

"......Test and Preview Buttons—The Test button permits easy viewing of sample data. You also can sample an entire file and print or display import log statistics (number of records imported, and more)....." Sorry Stephen; didn't mean to toss you under the bus here. I am just trying to make a point.

Just amazing............I don't know what else to say. The more I hear/see about this issue, the angrier I get.