when you're ordering from a staged file if you import all the price comes over, if you do it one by one you don't get the price. the price should fill in in both instances.
Can you please provide more details, maybe a screenshot if it is not a problem. I tried ordering a single record from a file, which took me to the new empty order with the price fields. On the other hand, I could not see price on the "Import All" screen.
Srdjan, When you ordered from the single record, there were price fields but they were not populated - or were they? When you order from a full file there is no price field, but when you finish the import you see the price on each line item. Video: http://screencast.com/t/JU7RrfmoVf
Created attachment 7341 [details] [review] patch
If price in 020$c has a currency symbol ( e.g. $12.00 ), this price will not be pulled over. If it is just a bare number ( e.g. 12.00 ), it works just fine. Is this expected behavior? As an aside, why does GetMarcPrice look for the price in 345$c? Field 345 is "Projection Characteristics of Moving Image", and doesn't even have a subfield c, let alone a price in it.
I'm going to revise my previous comment and state that this is good functionality. The price is only pulled if we are sure it is really a price. 020$c can contain many different things, not just prices. From the LOC 022 Page: 020 ##$a0802142176 (pbk.) :$c$1.95 020 ##$c$8.95 020 ##$cRs15.76 ($5.60 U.S.) 020 ##$cRental material 020 ##$cFor sale ($450.00) or rent ($45.00) 020 ##$cFor sale ($200.00 for 3/4 in.; $150.00 for 1/2 in.) 020 ##$c$4.95 (lib. bdg.) 020 ##$c$3.60 (pbk.) [Two prices for two items on one catalog record; no ISBNs are known.] I think ignoring 020$c if it doesn't contain just a numeral is safe, but stripping out currency characters, or using them to decide the currency would be better. Perhaps that should be a separate bug report.
I need to switch my opinion *again*. I stand by my previous statement, but the "Import All" option works with or without a dollar sign in 020$c. Since both should be functionally equivalent, the single record import needs to be able to handle this as well.
Can you please check if the behaviour was different before the patch? If it was, I will correct it. Otherwise, we should file a separate bug to make it work correctly.
(In reply to comment #7) I believe this behavior should not be considered different than before, and I have created and attached a separate bug report, Bug 7516 - Create Subroutine For GetMarcPrice that will discern the actual price from a given price field value. for this issue. > Can you please check if the behaviour was different before the patch? If it > was, I will correct it. Otherwise, we should file a separate bug to make it > work correctly.
Created attachment 7528 [details] [review] bug_7231: Call GetMarcPrice() in acqui/neworderempty.pl for staged imports
Created attachment 7529 [details] [review] bug_7231: Call GetMarcPrice() in acqui/neworderempty.pl for staged imports Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 7530 [details] [review] bug_7231: Call GetMarcPrice() in acqui/neworderempty.pl for staged imports
Created attachment 7531 [details] [review] [SIGNED-OFF] bug_7231: Call GetMarcPrice() in acqui/neworderempty.pl for staged imports
QA comment: small patch, use a sub instead of a copy/paste of some code
(In reply to comment #4) > As an aside, why does GetMarcPrice look for the price in 345$c? Field 345 is > "Projection Characteristics of Moving Image", and doesn't even have a subfield > c, let alone a price in it. The 345 is an alternate place for the price in UNIMARC. I don't know for MARC21
This patch will be included in the forthcoming 3.6.5 release (no string changes).