I replyed to your previous post with instructions, but I think you have
> a problem. randomweightupc only supports price up to $99.99. You
> need to switch to EAN, which supports up to $999.99
> UPC format: p#####s$$$$c
> p = prefix (2)
> ##### = 5 digit PLU
> s = secondary check digit
> $$$$ = 4 digit price
> c = check digit
>
> EAN Format: pp#####$$$$$c
> pp = prefix (20 or 02)
> ##### = 5 digit PLU
> $$$$$ = 5 digit price
> c = check digit
>
> The formats are not defined by RMS or Microsoft - they are industry > standards. >
> Glenn Adams
> Tiber Creek C> > How do I set up the following UPC scans to recognize the embedded price? >
> > Scan 200999001006, is the scan for $ 1.00
> > Scan 200999050004, is the scan for $ 50.00
> > Scan 200999187670, is the scan for $187.67
>
> > I am using POS 2.0.0105
>
> > I have checked the Utilize rendomweightEAN and UPC codes in the
> > Configuraton POS options tab, but I am having trouble from that point. >
> > Please help.
>
> > I would appreciate all the help you can give me.
>
> > Thanks,
>
> > Kent
Hi all, Ive read through the posts but havent come across a solution to my current urgent problem :( I work for a microsoft rms partner and we are implementing rms 2.0 for a clent in Zimbabwe. Most of their business is on weighted items. My problem is centred on the fact that their currency runs to ridiculous figures. For standard items this is fine as they is no limit to the digits on the pos however when it comes weighted scale items the label limit to 99,999 is a hurdle.
Is it possible to have a configuration on rms 2.0 such that the EAN label is read as weight of the item rather than price.
EAN Format: pp#####$$$$$c pp = prefix (20 or 02) ##### = 5 digit PLU $$$$$ = 5 digit price -----------------CAN YOU CONFIGURE TO READ AS WEIGHT 999.99 c = check digit
This would give an allowance of a weight of upto 999.99 kgs/lbs to which if exceeded they could always pack separately. The price figure would then be calculated by price=weight*price per unit weight Further this would mean that updating the scale prices would be irrelevant as the pos would always determine the correct price. If anyone has an idea how to get over this rms handicap let me know as i am getting hammered by my client with the argument that their archaic solution which we are replacing has this facility. Below is an extract of his latest email.
----------- Have you guys found a solution to the scale issue? Please respond urgently, as this is a major hurdle. The POS MUST be able to identify and then process barcodes of the form 20SSSSWWWWWWX or 21SSSSWWWWWWX where SSSS is the 4 digit lookup code, WWWWWW is the weight(prefix
20=variable weight) OR quantity(prefix 21=fixed price per unit). The POS should also be able to configure where to place the decimal point in the WWWWWW e.g. WW.WWWW or WWW.WWW. which our current system implements.
---------------- SOS