Sage 100

I have a client needing to import invoices into AP Data Entry. The import file has the invoice date but not the due date. So, we need to have the VI job calculate the due date based on the Vendors terms code. I have a sample 3.71 import job by Scott Brady at Sage that shows importing the invoice due date as a calculated date field with this calculation expression: CALC EXP: {AP.INVOICE:INVOICE_DATE}+NUM({AP.TERMS:DAYS_DUE}) I tried translating this to version 4.50 with this expression: {AP_InvoiceHeader.InvoiceDate$}+NUM({AP_TermsCode.DaysBeforeDue}) The check on the expression returns the error: Error #26: Variable type invalid. Any ideas?

Shouldn't the terms code default from the vendor and thus calculate it correctly?

You don't need to bring in as much data as you used to in 3.71, not even the terms code. Try it without and see what happens.

That's what I thought

Trying it now. I'll let you know.

You are absolutely right. Thanks so much.

Similar issue yesterday. https://90minds-com.socialcast.com/messages/13107548?ref=stream Looks like we have two more happy campers.....

Sometimes we make it harder than it has to be. Plus, it's hard to forget old habits...

Yes, it IS hard to believe that V4.x actually makes some things easier.........

I seem to have a problem with making things harder than they need to be. Now I could kick myself for wasting time trying to do something the program will do by itself. I need new programming for my brain!

When you are in Import Job Maintenance on the Data tab, you'll notice the fields are different colors. I could be wrong, but this is my understanding: Blue - Required Pink - May be required but not necessarily (may come from a masterfile i.e. Vendor, Customer, etc.) Red - Optional (I think? May serve a purpose, e.g. LineKey?) Green - Default to the most common option, usually Yes/No fields. Black - Although not required, these are usually the fields you want to populate e.g. Amount. (Importing an invoice without an amount is kind of pointless!) Anyone else care to expand?

Pretty much what the BLS KB has. I copied this from a MAS help file some years back. Visual Integrator Import Field Color Meaning This list box displays fields from the data file selected on the Configuration tab. The fields are color-coded as follows: Fields that appear in blue are required fields. Fields that appear in cyan are required fields that have dictionary default values assigned to them as a starting point for a new job. Fields that appear in magenta are conditionally required fields and are validated at the time the record is written. These fields cannot be validated during a test import. Fields that appear in black are not validated; however, these fields may be required (for example, numeric fields for quantity or price). Read-only fields will be displayed in red in Import Job Maintenance All required fields must be selected for import. User-defined fields are listed at the bottom of this list box with a UDF_ prefix. Attached is a screen shot from the MAS help files......

Thanks @JeffSchwenk - I was winging it...

Flying like a pro!

@JaneCavanaugh Yesterday, right in front of the client's own eyes, I was able to set up the AR invoice import VI script in SAGE ERP 100 version 4.50 PU#4 with fantastic help from @ThereseLogeais and @JeffSchwenk. Yea! Today back in the office, I am struggling to accomplish the same import in AP. If you would care to share your working AP Invoice import VI job, I'll send back my working AR Invoice import job to you! My e-mail is mmcd@72ho.com. Thanks!

I think that's was @DianaLaughner 's doing yesterday but what kind of issues are you having with the AP import?

I NEVER set up the import in front of the clients eyes!!! Always best to wait a couple days before delivering. Client tends to equate time with value. If they see that you put it together in 45 minutes or so, they might not want to pay the $500 - $1000 of VALUE that it is worth to them. And they NEVER see you sweating bullets like you are today trying to get the same one to run........ I seem to run a 4/1 ratio, 4 frustratons for every EASY one. And as you point out, even the easy ones become hard under certain circumstances..........

AP can be strange because of sales & use tax, job cost, divisions, discounts, import file format or other quirky items. Post up the VI and so we can take a look.

@ThereseLogeais I keep getting the error: ""L record AddLine() Failed. Missing or Invalid Header"" even though I followed SAGE's instructions to remove all items in the Reords tab. I am dealing with Batch Entry in AP. No Job Cost, no Divisons, No discounts required. I will post the VI job a little later today.

@MichaelMcDonald are you importing the batch number?

@Michael - I emailed you a very basic import. Wayne also started a place for all of us to share our imports and as soon a I find where that is, I will upload the import there also.

(And I have to admit I think of the Doobie Brothers. every time I see your name. I had a former co-worker who LOVED Michael McDonald...)

seems like AP imports are the rage right now. Just did a job to import manual checks because the parent company is now paying all invoices on behalf of the child company who uses MAS. (excuse me..Sage 100) The system doesn't check to make sure there is a vaild invoice being paid. It just imports the transaction. so if the parent company doesn't have the invoice number exactly right the import doesn't catch it. It needs a perform logic statement.

Access front end?

a perform statement that checks for valid invoice numbers for manual checks would be the preferred way but, pre-processing the file is what they are now doing. Trying to get away from having to do that. SWK gave me a quote for some lines of logic in a custom perform statement. The approach would be simialr to a statement that Alnoor created to look for historical invoices when bringing in new invoices.

Here are the errors I get when I ""test"" the import;

Here is the VI job to import AP Invoices

Take the terms code out of the data tab for beginners. Also, import the account key into a temp field and then calc the account key using the temp field (are your actual account numbers longer than 9 characters?) No matter the import, I always import the account #' into a temp field, then calc the account key. I have also found that testing isn't always a good way of ""testing"" as it gives false positives. Do it for real to see what the errors are. If after deleting the terms code, you are still having difficulty, I would turn off batch processing and retest without the batch line. Also, why are your run time assigning the batch number? Too slow. Just hard code the batch number (e.g. 100) and use it. If you are doing multiple batches at once, use the NEXT function to assign the batch. Way easier. My money is on the terms code and the account key. Keep us posted.

You could also delete the invoice due date and the invoice discount due date....

Good point! Rule of thumb is that now you only have to import fields that you actually enter manually. If you don't override the default values, leave the field out.

Michael - I just sent another ap invoice import that I used today without problem. It is from version 4.30 but should work with 4.50 since the fields between 4.30 and 4.50 AP didn't change (at least I don't think they changed).

It's the less is more, I believe...

I'm looking for the syntax to actually calc a date field on a VI import in v2013. Need to calc the Invoice Due Date via Invoice Date + 10

Why not just create a terms code of invoice date + 10 and assign that terms code?

@BrettZimmerman - Use the JUL function to convert the invoice date to a Julian date. Add the 10 to the Julian date and then convert back to the due date.