maineiac13

I want to add a new stamp category. So I opened the Stamp Data Manager. I then clicked on "New Category"....but nothing happens. I closed down SM and re-opened it again to see if that might help but the same thing happened again. Is there a problem with the program or just some issue with my computer? NEVER MIND....I just realized it works fine.

Not sure I understand your question. Using a specific example. Let's say that I enter US stamps #5252 and 5253. Both have a MVF value of $.90, but I have 3 of #5253 and only 1 of #5252. After entering those stamps, when I look at the main collection page it will show that the "current value" for 5252 is $.90 and the "current value" for 5253 is $2.70. In reality of course the current value of #5252 and #5253 are both $.90, but #5253 shows as more only because there are 3 in my collection instead of 1. I don't have a problem with a column that shows the total value of all of the #5253s in my collection, but would also like to be able to see immediately the individual value of the stamps, not just the total value and then have to remember to divide by the quantity to find out the individual value. What is even stranger is that if you "click" on the "Current Value" column to sort the collection by that column, the sort does not actually use the values in that column for the sort....instead it sorts on the individual value of each stamp rather than the cumulative values shown in that column. So, in the example I just gave, the two stamps would be sorted together for value purposes even though the actual $ amount showing would not be the same. So obviously, the information about the individual stamp value is retained in the system....but there is no column to show that.

When I go into my collection, one of the available columns is titled: "Current Value" That column represents the value for the specific item multiplied by the quantity. So for example, if one has a stamp that is valued at $5 with a quantity of 3, the "Current Value" shows that listing as $15. But as far as I can tell there is no column available to show the value of the individual item (in this case it would be $5) Is it there but I just am missing it? If not, it would be a good addition since when looking at a collection, it makes it difficult to immediately see the value of stamps if the current value represents the cumulative value not the individual value.

Yes, that is another way to add values. However, the problem I reported is that SM allows you to add the values after one has added new stamp varieties in the Stamp Data Manger and before that screen is closed. If you do that, however, once you then close the Stamp Data Manager, all those new values that you have added are lost. Ideally, (1) SM should be changed to retain those values, or (2) SM should prevent one from adding values at that point or (3)at least there should be some kind of warning that any values added before first closing the Stamp Data Manager will not be retained.

In the meantime, it would be good if the system blocked users from entering values in this circumstance since they are not maintained in the database once the Stamp Data Manager is closed.

So I decided to use the Stamp Data Manager to add a large (100+) group of stamps to the Austria database. Went through the usual process of adding all the stamps then went through and added the various values for all of the new stamps (eg. mint vf, use vf, etc.). All those values showed up in the Stamp Data Manager. Then I closed the Stamp Data Manager. Then opened the program to actually add the stamps from my collection.....but....while all the stamps that I had added appeared, NONE of the values were showing. So I went back to see what was happening and it turns out that if you add stamps via the Stamp Data Manager you can not add values to those stamps you have just added unless you first close the Stamp Data Manager before adding the values and then re-open the Stamp Data Manager and THEN add the values. A very frustrating situation....and I suspect it is the reason that I see so many stamps that have been added to the data base in recent years but with no values. I think people either don't realize the problem or if they notice it, they don't want to go back and re-add the values after spending a lot of time doing it originally. Any chance that there may be a fix to this???

I am often adding large groups of stamps at one time. In many circumstances, the particular format or grade or hinge category of stamp (block, fdc, mint vf, sheet, etc.) is not priced in the data base at the time that I add the group of stamps. Consequently, I then go back and add the value for each stamp based on the variety of the stamp. In many cases, there are a group of stamps which have the same value for the particular variety and it would be a lot simpler if in addition to the "cost" box that appears in the Properties Dialog when modifying groups of stamps already in the collection, if there was also a "value" box. Thus one could easily add values for large groups of stamps in the collection all at one time. Hope what I am suggesting is clear. 😀

Thank you for the reply. It would be great if this was fixed in that update as the current problem makes it very time consuming if there are many new numbers to add.

In the past when I have added new stamp numbers to an existing country data base using the Stamp Data Manager, I was able to add all of the new stamp info., then click on the apply button, which would retain the information I had just added and increase the stamp value by 1 digit...which would allow me to make any necessary changes to the data fields and proceed along to easily add additional stamp numbers. Now, however, when I am using SM2020, the "apply" button is greyed out so I can only add one stamp number at a time and must repetitively add the detailed information even if it is roughly the same as the immediately prior stamp number I have just added. Is this a bug in SM2020, or am I possibly doing something wrong?

Even the delete 1 pattern changes quickly as the numbers in the curreent SM Poland database during 2008-2010 often give whole numbers to stamps where Scott has assigned them as small "a", "b" etc. I have gone through and corrected all the numbers for that period and changed the images accordingly and have updated the info to SM. My next step will be to add stamps from 2010 to the current period when I get a chance. Though another issue has cropped up as will be mentioned in another post shortly.

I recently acquired a collection of Poland stamps and will soon be in the process of entering them into SM. I was glancing through the Poland database just now and noticed that there are quite a bit of problems with it. I have only looked at the general issue stamps so far but here are some of the problems. First, the general issue stamps have not been updated since 2010 (yes I am using SM 2020). Additionally, beginning in early 2008 the the Scott numbers are wrong. And additionally, by the middle of 2008 there appears to be an entirely different numbering system being used as suddenly the numbers jump from 3900 or so to 4900 or so and unfortunately they still do not even correlate with the correct scott number if you change the first number from a 4 to a 3. (And those numbers do not correlate with any recognized numbering system i.e, not Michel, Yvert, or even Fischer.) So is this or will this be looked at by SM or is this something that we users (I guess namely me) will have to take on...though my last effort at doing something like this for Monaco never seemed to make it into the SM database so I am reluctant to start doing this again.

I am using SM2020. When I customize the toolbar to show text labels, that customization is not retained when I close the program and then re-open it. Is this a bug or intentional?

Sure...I'll send you an email

I have finally had a chance to take a look in detail at the Monaco images which are in SM2020 and compare them with the images that I submitted to Admin last summer. It turns out that some of the images I submitted made it into the new SM2020 Monaco images after all. But there are a number of major problems nevertheless. First, I submitted the images in 3 separate files. The first contained about 800 images, while the 2nd and 3rd contained about 1000 each. (There is a 4th set which I have not yet submitted which has also been prepared.) Only some images from the first submission are included in Monaco SM2020 images. None of the 2000+ images submitted in parts 2 and 3 are included. Also, when I submitted the images I did include some images where SM2019 already had images. I did this for 2 reasons. First, there were some cases where SM2019 had the wrong image for the stamps. And second there were many Monaco images in SM2019 that were quite poor compared to the images that I was able to provide. Below are examples of what I am talking about. In each case, the first image is the present image in SM2020 and the second image is the image I provided. In particular, note the first set. This is the image for Scott #1. The image currently in SM2020 is NOT Scott #1, but rather Scott #C69!! The other 3 examples are for Scott #s 14, 17, and 20 respectively and show examples of poor quality images on the left that I had hoped to improve by uploading the images on the right. Most importanly, however, is the fact that there are still more than 2000 images that are still completely missing from the Monaco image folder which I submitted. If I need to re-submit them, please let me know.

Disappointed that there has not been an admin response

First some background: I have a virtually complete collection of mint Monaco issues, from #1 through the issues of 2019. When I purchased StampManage 2019, I was disappointed to find that there were only about 1000+ images in the Monaco image folder instead of about 3800+ which would represent all the stamps. Also, in addition to the many stamps which had no images there were more than 1000 stamps omitted entirely from the database. And there were more than 1000 stamps which though appearing in the database had no pricing information whatsoever or only pricing for used stamps, etc. So, having the time and the interest, I decided to do something about this. First, working directly with Paul at StampManage, I ultimately uploaded more than 3000 images of stamps taken directly from my collection. For a variety of reasons it was easier to do this by sending them via DropBox to Paul rather than through the regular submitting process within the program. Additionally, I added values for the missing information in the database and added and corrected the stamp information so that all stamps were shown. This was all completed by about the end of June. About that time, an update for StampManage 2019 was released though none of the changes that I had done were yet included. I had previously asked Paul what would happen to my database if I installed the July update and he expected that my own changes would remain even though they were not in the update database. I installed the new update (though I backed up my database first). The good news was that my database still included all the images I had created. The bad news was that the update overrode many of the pricing changes I had made. For "new" Scott numbers that I had added, there was no problem. However, for all of the many Scott Numbers where there had been no previous pricing at all or where I had added missing information for mint stamps, etc., that information was stripped from my database after installing the update. Since i had made a backup of my pre-update database I was able to reinstall my own database...but as a consequence, was unable to utilize the update. Fast Forward to StampManage 2020: I was looking forward to the new version of SM2020 so that I would be able to update my database not only for Monaco but for the other countries I collect. To be safe I decided to download SM2020 onto a different computer from where I have SM2019. Immediately I discovered that still NONE of the 3000+ images I submitted to Paul were added to the Monaco image folder. Additionally, while the Monaco database now includes the NEW Monaco stamps that I added through about March 2019, it includes none of the pricing information I added for those stamps or for the previously existing stamps where I added pricing information. So, absent some clarification of when, how and whether the updates I provided are going to make it into SM2020 it seems that it does not make sense for me to update to SM2020. And I wonder how many others who have uploaded similar information to SM for other countries may not realize that their information is not making it into the program and/or may be overridden when updates are installed?

Yes...for some reason it was set to 0. Changing it to 1 corrected the problem. Thank you.

I just downloaded and installed the 2020 version of the deluxe program. (I have not yet activated it because I need to check out some problems before I go ahead and activate it.) I downloaded it to a different computer from where my current database is located to be sure that I could clearly see what is in the version without any interference with changes that I have made in my own database. So when I go to the "add stamp" area and click on any country, every single stamp shows either as no value or a value of $0.00 for all categories (eg., fine, vf, used, mint, etc.) Any idea what is happening here? And what I can do to get the prices to show? Thanks, Ken

Just noticed there is a new update (free)available. When that is installed, what impact will it have on changes I have made to the database which have not yet been sent to Liberty Street and which are thus not part of the new update database. Will that database overwrite my database changes?

In reality I should be entering “tab single stamp” as the category and mint or used f or vf , etc. in the condition field. I do not agree with entering the “type” of stamp in the condition field. I do not understand why you have created a system where if I make an entry into my own inventory of a condition which was not previously listed in the data manager for a particular stamp, that this entry automatically gets input into the data manager as a value which will now appear for that stamp as if I had directly entered that info for a single stamp into the database. I suspect that lots of collectors have categories of their stamps that are not hard coded, eg. blocks of various sizes, pairs, strips, half sheets, etc. and I understand not necessarily hard coding all of that...but if one happens to be cataloging such items, and then it turns out that one uses a condition that was not previously input into the database, I can’t see why that value is suddenly put into the database when the collector really had no intention of modifying the database that way. It would seem a much better idea to have modifications to the database created only when the collector really wants to specifically do that.

I recently purchased a group of early Israel mint tab singles which are valued at a significantly higher amount than the corresponding mint singles..without the tab. Since “mint tab” is not a category that is included within the “hard coded” options (eg, pb, line pair, fdc, etc.) to add these stamps to my inventory I simply added that variety for my own inventory. Then I noted that the stamp was “mint-fine” and entered my chosen value for the stamp. Here is where the problem arises. The stamp data manager for these stamps includes a value for mint-very fine, but does not have a value for mint-fine. However, once l entered the mint tab stamps in my inventory, the values I selected (for mint-fine mint tabs) now shows up not only in my inventory, but also appears in the data manager and thus reflects a significant anomaly where mint-very fine shows up to be valued much lower than mint-fine. This, despite the fact that I did not directly make any changes to the data manager. So, when I eventually make changes on my own to the data manager, and upload them, these changes will show for others as well. And anyone else who then uses the database in future years will be confused as to why the vf price is much lower than the f price. And if they go to enter a mf value for a mint stamp rather than a tab stamp they will be entering a value which is far in excess of the real value. My point is, that I do not think these kind of personal inventory valuations should find themselves automatically entered into the database. (And I guess this may explain why I have noticed other cases even in the US database where f was higher than vf...presumably because of a similar situation.) Any thoughts on this from others?

Also just noticed that the changes I made, though not uploaded yet, show in the "Database by Contributors" already merged with the other person with my same name.

I am working on a major effort on a country and have not yet uploaded the changes to the internet. One thing I have noticed is that in my local version of the stampmanage catalog, my name appears showing that I have made the changes. However, I also noticed that someone else with my same name is shown as a contributor for other changes already incorporated into the overall database. So, once I upload my changes to the internet and they are incorporated into the overall database how will one distinguish between the two contributors?

As far as I know mint tab is only for Israel. But it is a major component of Israel stamp collecting.

Okay....now I see how I could add a value for a missing line pair for a coil or a sheet value for a regular stamp, etc. Another question. Israel stamps are mostly collected as mint tab stamps rather than just mint single stamps. Scott generally shows values for both mint singles and those with tabs as separate entries. Yet there is no value field for mint tab stamps in the STAMPMANAGE CATALOG >2019. Can a value field be added for that and if so how does one go about doing that? If so, then I might consider a project to value the Israel tabs for the database.