From: ExsonQu <hex...@gm...> - 2014-06-11 07:27:13
|
*Dear all,* I've received a question about the Port definition in PO header. Since it's only defined in suppliers table but there is no place to input and the definition is varchar(200). And when we input it in the PO_header.php, it will not be kept. And the code said it's should be locations' loccode. And the port defined in purchorders is varchar(50). I believe about definition has conflict. My question is what the actual purpose of this field? If it's supplier's port, we should revise suppliers.php. Any comments are highly appreciated! And thanks in advance! Best regards! Exson -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
From: Phil D. <ph...@lo...> - 2014-06-11 11:01:54
|
Yes - I don't think this "port" field is needed and should be dropped I think. I am not sure about your change to the import script Exson - we need the mb string functions to deal properly with utf-8 Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 11/06/14 19:26, ExsonQu wrote: > *Dear all,* > > I've received a question about the Port definition in PO header. > > Since it's only defined in suppliers table but there is no place to > input and the definition is varchar(200). And when we input it in the > PO_header.php, it will not be kept. And the code said it's should be > locations' loccode. And the port defined in purchorders is varchar(50). > > I believe about definition has conflict. My question is what the actual > purpose of this field? If it's supplier's port, we should revise > suppliers.php. > > Any comments are highly appreciated! > > And thanks in advance! > > Best regards! > > Exson > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
From: ExsonQu <hex...@gm...> - 2014-06-12 02:07:23
|
*Hi, Phil,* Thank you for your nice reply. I'll remove it later. Thank you for reviewing my revision. For multi-byte character set, the comma is not coded in '44' as ASCII, at least in Chinese characters set. So it'll not destroy the delimiter function of csv files. The actual one make the delimiter failed is the ASCII coded 44, unfortunately, mb_strpos() failed to to sort it out. The strpos() does. The solution at least work for Chinese characters. If any mistake, please correct me! Thanks and best regards! Exson -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516p4657518.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
From: Phil D. <ph...@lo...> - 2014-06-12 06:53:26
|
Hi Exson, I wondered why we don't just always enclose the output in quotes and why there needs to be a test to see if there is a comma in it at all. Couldn't we just always quote ... I'll commit this to see if it works for you? Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 12/06/14 14:06, ExsonQu wrote: > *Hi, Phil,* > > Thank you for your nice reply. I'll remove it later. > > Thank you for reviewing my revision. For multi-byte character set, > the comma is not coded in '44' as ASCII, at least in Chinese characters set. > So it'll not destroy the delimiter function of csv files. The actual one > make the delimiter failed is the ASCII coded 44, unfortunately, mb_strpos() > failed to to sort it out. The strpos() does. > The solution at least work for Chinese characters. > > If any mistake, please correct me! > > Thanks and best regards! > > Exson > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516p4657518.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
From: ExsonQu <hex...@gm...> - 2014-06-12 23:47:36
|
*Hi, Phil,* Thank you for your ideas for this. It's sure that your solution will fix the fields input with comma problem. I think the design for this consideration at least has one consideration is to separate number from text string.When the fields content is quoted, it'll be handled as text string even it should be a number. In excel or open office's data sheet, the number properties will lost due to this change. Thanks and best regards! Exson -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516p4657520.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
From: Phil D. <ph...@lo...> - 2014-06-14 02:35:27
|
Ah yes I see.... tricky! Not sure what the best solution is here - but it seems incorrect to be using the non- multi-byte character functions when we are using multi-byte character set. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 13/06/14 11:46, ExsonQu wrote: > *Hi, Phil,* > > Thank you for your ideas for this. > > It's sure that your solution will fix the fields input with comma > problem. I think the design for this consideration at least has one > consideration is to separate number from text string.When the fields > content is quoted, it'll be handled as text string even it should be a > number. > > In excel or open office's data sheet, the number properties will > lost due to this change. > > Thanks and best regards! > > Exson > > > > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516p4657520.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
From: ExsonQu <hex...@gm...> - 2014-06-14 05:18:30
|
*Hi, Phil,* I think the compromise way is to add the strpos() to the original scripts. if( mb_strpos() or strpos() ) { } else{ }; I've test mb related function before and it seems there is some uncertainty with them. This topic seems more complex then their looks. Best regards! Exson -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/What-s-the-real-meaning-of-Ports-tp4657516p4657522.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |