Sage 100

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

...and if you preview the report i Crystal do you see the symbol(s)?

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

I don't see the symbol in the crystal report.

...and if you preview the report i Crystal do you see the symbol(s)?

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

That is odd. I inserted the symbol in Word (Insert, Symbol), then copied and pasted it to the end of an item number by editing in dfdm.  I was able to preview and export and see the symbol.

I don't see the symbol in the crystal report.

...and if you preview the report i Crystal do you see the symbol(s)?

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

That is odd. I inserted the symbol in Word (Insert, Symbol), then copied and pasted it to the end of an item number by editing in dfdm.  I was able to preview and export and see the symbol.

I don't see the symbol in the crystal report.

...and if you preview the report i Crystal do you see the symbol(s)?

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

What font are you using in Crystal reports for the item code field?

Thank you Doug. I really appreciate you helping with this. I tried doing this and it exports a blank space. I wonder if it's not actually the ß character and it's actually a hidden command that shows like that. 

n formatting?

I added the β to the end of an inventory item and it exported correctly using the TTX format.  It worked with the Segoe UI Symbol font and the Arial font.

Yes, it exports a space in place of the bad characters. I tried VI export also. I believe I need to get this character exported ß

Have you tried using Crystal to export the data?  I would try using tab-delimited format as the file type.

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Last time I addressed this for a client was in August, and we had to go through DFDM to remove lots of bad ß characters from the applicable records.  I did consider a VI import but can't recall how far I looked into it, so I'd be curious to know if anyone gets it working.  This data corruption is often the result of copying/pasting into Sage 100, and not backspacing over any extra spaces/characters.   

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

For what it is worth, we have been able to fix this in Sage 100 Premium with Scripts, but you have to check a zillion tables where that Item code might exist, including Sales Order, SO History, AR Invoice History Detail, etc. etc. etc.  

Last time I addressed this for a client was in August, and we had to go through DFDM to remove lots of bad ß characters from the applicable records.  I did consider a VI import but can't recall how far I looked into it, so I'd be curious to know if anyone gets it working.  This data corruption is often the result of copying/pasting into Sage 100, and not backspacing over any extra spaces/characters.   

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Are you able to share the script?

For what it is worth, we have been able to fix this in Sage 100 Premium with Scripts, but you have to check a zillion tables where that Item code might exist, including Sales Order, SO History, AR Invoice History Detail, etc. etc. etc.  

Last time I addressed this for a client was in August, and we had to go through DFDM to remove lots of bad ß characters from the applicable records.  I did consider a VI import but can't recall how far I looked into it, so I'd be curious to know if anyone gets it working.  This data corruption is often the result of copying/pasting into Sage 100, and not backspacing over any extra spaces/characters.   

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

The attached SQL script is for Sage 100 Premium and comes with all the usual disclaimers - make backups, run in a test company first,  Have the client check the results in test company, etc.

The script looks for the following characters in the Item Code :

• Space as first Character
• Space as the last Character
• CHAR(10)  (LineFeed)
• CHAR(9) (Tab)
• CHAR(13) (Carriage Return)

We have used this successfully for one of our clients and they reach out to us every 6 months or so to have us re-run it since employees continue to cut/paste from websites and excel and word.

The list of files in the script has been built over several iterations and corrects over 120 files. Is that EVERY file??  We feel that it is pretty comprehensive but probably not all-encompassing depending on what modules or third-party products are installed. For some files, there are already duplicate records with a "good" item code and a "bad" item code, so script deletes the "bad" record. Other tables where the item code is not part of the key field, it simply cleans the bad characters from the item code field and saves the record. With that said, I would recommend rebuild sort files in all modules after using this. 

I hope it is helpful at least as a reference. 

Are you able to share the script?

For what it is worth, we have been able to fix this in Sage 100 Premium with Scripts, but you have to check a zillion tables where that Item code might exist, including Sales Order, SO History, AR Invoice History Detail, etc. etc. etc.  

Last time I addressed this for a client was in August, and we had to go through DFDM to remove lots of bad ß characters from the applicable records.  I did consider a VI import but can't recall how far I looked into it, so I'd be curious to know if anyone gets it working.  This data corruption is often the result of copying/pasting into Sage 100, and not backspacing over any extra spaces/characters.   

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Last time I addressed this for a client was in August, and we had to go through DFDM to remove lots of bad ß characters from the applicable records.  I did consider a VI import but can't recall how far I looked into it, so I'd be curious to know if anyone gets it working.  This data corruption is often the result of copying/pasting into Sage 100, and not backspacing over any extra spaces/characters.   

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Yes, That's what we're noticing. We're trying to figure out what character it actually is so we can import it.

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

For just one I'd use the Sage interface / lookup when doing the renumber.  For more than one, try this as a button script:

retVal = 0
sItemCode = "" : sOutputText = ""
retVal = oBusObj.GetValue("ItemCode",sItemCode)
sOutputText = sOutputText & "Item: " & sItemCode & vbCrlf
if len(sItemCode) > 0 then
    for i = 1 to len(sItemCode)
        sOutputText = sOutputText & "Ascii(" & cStr(i) & "): " & cStr(Asc(mid(sItemCode,i,1))) & vbCrlf
        sOutputText = sOutputText & "Unicode(" & cStr(i) & "): " & cStr(AscW(mid(sItemCode,i,1))) & vbCrlf
    next ' i
end if
retVal = oSession.AsObject(oSession.UI).MessageBox("", sOutputText)

...it should give you a list of the ascii characters that make up the Item Code.

Yes, That's what we're noticing. We're trying to figure out what character it actually is so we can import it.

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Yes, That's what we're noticing. We're trying to figure out what character it actually is so we can import it.

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Can your program get the length of the field?  If so, you could have a program examine each character until it discovers a character that is not in A -Z or 0 -9.  When it discovers the strange character then add "ZZZ" to the end of the last valid letter or number.  For example:

A$=ItemCode$

Dim string NewItem$

read (len( A$)); 'returns 10

For X = 1 to 10 read(A$(X) until A$(X,1) not in [A,B,C, ... 0,1,2,3,etc]

Let NewItem$= A$(X-1)+"ZZZ"

Write(NewItem$)

Delete A$

Yes, That's what we're noticing. We're trying to figure out what character it actually is so we can import it.

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer. 

Could possibly work. Thank you for this. I'll send it over the programmer and report back.

Can your program get the length of the field?  If so, you could have a program examine each character until it discovers a character that is not in A -Z or 0 -9.  When it discovers the strange character then add "ZZZ" to the end of the last valid letter or number.  For example:

A$=ItemCode$

Dim string NewItem$

read (len( A$)); 'returns 10

For X = 1 to 10 read(A$(X) until A$(X,1) not in [A,B,C, ... 0,1,2,3,etc]

Let NewItem$= A$(X-1)+"ZZZ"

Write(NewItem$)

Delete A$

Yes, That's what we're noticing. We're trying to figure out what character it actually is so we can import it.

It is absolutely not the ß character.  That is just how invisible characters are shown in DFDM.

See the picture below:

Line 1, our programmer imported the missing character. 
Line 2 I selected manually. 
Delete and Change log shows the first one was skipped because item was not on file.
The second manual one worked.
Looking at DFDM the lines look identical.

The ß character seems to not really be that character in Sage. But it shows like it is.

If they were caused by copy/paste from Excel it should be CRLF.  Try a Crystal Report with a formula to replace chr(13) and chr(10) with temp characters (like "^", "%"...) then in your VI import to bring them back, do a formula to bring back the original characters.

If that doesn't work (meaning the invisible characters are stripped by ODBC) try hard coding in the extra characters within the VI job... not relying on having them in the source file.

No, they were coping and pasting the whole cell in excel. If there's an enter in the cell it will copy to Sage as that hidden character. They should've double clicked the cell and copied just the data. Not the whole cell.

I'm willing to bet they have Scanco Multi Bin or the old WO module. if memory serves me right i traced it to one of these two.  

Thanks Kenny that helps. I dont want to chase my tail on this. Might be a good idea to add the A then merge. Maybe I'll just do it in smaller blocks of items. 

I have run into this a few years ago. Sage100 will not let you import that character regardless of the font. It's not a valid character as far as for Sage100 is concerned. I only had like 10 items, so I manually renumbered via DFDM, I removed the weird characters and added an A to the item number, both in Item Master and in the History files. Then I was able to Merge the two. I know you have a lot more items. I wish i had a better answer.