RE: [Web-erp-developers] Serial Stuff

[Jesse P. <jes...@st...>]

It sounds like we're back at the time I picked up WebERP except that it =
actually had some beginnings of Serialised support. I will have to look =
at how much it has changed since it sounds like you've taken my changes =
and basically rewritten them to better suit your views without much =
change in functionality before I can levy an opinion on it. Is this all =
in current CVS?

Remember that I was originially trying to give you a preview of where I =
was going with my work - it was not and is not a finished piece. The =
abstractions were done to simplify perusing the code in the various =
files and breakout functional pieces - I believe I mentioned that I =
found it quite cumbersome to wade through all the code, especially as =
horribly important code became intermingled with, say, HTML sections. =
They also were not completed.

I have to say that Dick made some quite valid points. I don't know PEAR, =
but following some recognized standard may help in readability. I think =
the problem arising between your and my coding is not something PEAR =
covers - it's more of a 'coding philosophy' thing, with my approach =
being mostly backed by recent computer science training. To that end, =
and in trying to not completely overwhelm you with changes, much of what =
I did was intended more for you to take at face value, as in 'that =
works, isn't in my way, and I can work around it'. I believe Dick more =
subtly hinted at that statement.

bottom line=20
	A) I need to see the changes.
	B) Either way, we must define how Serialised & Controlled stock must =
work to come close to staying on the same page. Your knowledge and =
apparent need/desire/ability to do this was one of the things that =
really attracted me to WE.
	C) I still like, have a great need for, and see great potential in this =
project, so I sincerly doubt you will see me just drop off.


jesse


> -----Original Message-----
> From: Stins, Dick [mailto:DR...@Zi...]
> Sent: Saturday, May 22, 2004 04:41
> To: web...@li...
> Subject: Re: [Web-erp-developers] Serial Stuff
>=20
>=20
> V
> ----- Original Message -----
> From: "Phil Daintree" <ph...@du...>
> To: <web...@li...>
> Sent: Saturday, May 22, 2004 6:28 AM
> Subject: [Web-erp-developers] Serial Stuff
>=20
> > Jesse,
> >
> > Your gonna be mad!
> >
> > I have done a fair bit on this and have GoodsReceived.php and
> > GoodsReceivedControlled.php going ok - with keyed input only at this
> stage.
> > The changed scripts are:
> >
> > GoodsReceived.php
> > Locations.php;
> > PO_Header.php;
> > PO_Items.php;
> > Stocks.php;
> > config.php;
> > doc/Change.log;
> > includes/ConnectDB.inc;
> > includes/DefinePOClass.php;
> > includes/PO_ReadInOrder.inc;
> > sql/upgrade2.8-2.9.sql;
> > sql/web-erp-demo.sql;
> > sql/web-erp-new.sql;
> > GoodsReceivedControlled.php;
> > includes/DefineSerialItems.php;
> >
> > I am a worried that you may not like what I have done to your serial
> stuff. I
> > really need help with this and if you bail on me now cos=20
> you dont agree
> with
> > my direction, I am in trouble. So, I am writing some pre-emptive
> explanations
> > ....
> >
> > web-erp has adopted a bunch of conventions which I am keen=20
> to ensure go
> right
> > through. I don't think other methods are wrong, just they are not
> consistent
> > with the style used here. Having adapted to those conventions it is
> > confusing, at least for me, to look at code written without=20
> using those
> > conventions. Consistency of application of these=20
> conventions throughout
> are
> > important to me. I have spelled these conventions out=20
> elsewhere in the
> > developers list. Perhaps for a younger mind this is=20
> probably a non-issue.
> >
> > I have worked through the GoodsReceivedControlled Code and=20
> notice that
> much of
> > the code for PO items received is actually in the=20
> StockModules - since it
> > will only ever be used from the goods received script I=20
> prefer all code
> > relating to that function to be in that one place so the=20
> reader doesn't
> have
> > to conceptualise through several stages of abstraction. I know the
> computer
> > scientists would choke on this, but if the code is not=20
> re-used or re-used
> > only once then the cost in terms of abstraction is too much=20
> (for me). I
> > concede that this is wrong and contrary to accepted wisdom=20
> - but I just
> can't
> > see it.
> Phil,
> When you use good names for intuitive=20
> functions/classes/method, then it
> should improve readability. Having not all code in the same=20
> script will
> improve quality, because only the changed code can raise new=20
> errors. So by
> splitting scripts, you will have a big advantage for the=20
> maintance, since
> you reduce the creation of errors and this will also reduce=20
> the testing
> effors.
> You allready accepted the concept of splitting scripts for=20
> readability,
> since you use include files, several scripts instead of one=20
> and only one
> script for web-erp.
> When you want an overall controlling coding standard, then=20
> please use the
> PEAR standards. I do also not like every detail in this standard, but
> adopting this standard will prevent discussions like this and=20
> might attract
> high qualified PEAR developers and prevents you and =20
> developers redoing
> coding.
> Since web-erp will be growing and growing, you finally will end with a
> system which can't be controlled by one person like you do=20
> now. To keep
> control over this project, you need a higher abstraction level and
> concentrate at business functions and component based=20
> development instead of
> bothering about coding details.
> Setting up new ideas for anarchitecture with a data ayer,=20
> business rule
> validations, ... might a much better improvement.
> Setting up development procedures might be effective:
> - functional/technical design/development conform standards (PEAR)
> - testing
> - releasing/configuration management (CVS)
>=20
> I am personnally more worried about bugs in WEB-ERP then=20
> different coding
> layout styles.
>=20
> with best regards,
> Dick
> >
> > The StockModules Stuff .....
> >
> > I see what you are doing allowing for alternative=20
> validation and separate
> > treatment of other types of stock - I so see the value in this
> approach....
> >
> > Information specific to the type of stock is stored in my=20
> stockcategory
> table
> > and perhaps the parameters for validation would be better=20
> held together
> with
> > other like information in that table, rather than hard=20
> coded and adding
> > another level of abstraction for those of us who suffer=20
> with them. I have
> not
> > coded up this but see no problem in doing so. Where=20
> specific additional
> > inserts for new tables peculiar to the business are=20
> required this will
> always
> > require modification of the code - I like to keep the code=20
> nice and simple
> so
> > other folks can grasp it and add their flourishes to it.
> >
> > When I took out the purchase order receive stuff from the
> GenericStockModule,
> > there really wasn't enough left to justify its existence.
> >
> > It was on this basis that I dumped the StockModules stuff. Instead I
> created a
> > DefineSerialItem.php object that just defines the data in=20
> the SerialItems
> > array and validates it before adding it - just as I did=20
> with the other
> > scripts using arrays of multiple variables.
> >
> > I have the GoodsReceivedControlled.php working for manual=20
> input/bar code -
> I
> > defaulted to manual input mode and lost the choices before input was
> > possible. I felt that from a users perspective this could be tedious
> having
> > to select an input method - before diving in with the input=20
> of serial nos.
> I
> > don't have the file input stuff going, this again looks a=20
> bit tough for
> me.
> > I've left it in - just commented it out - it needs some TLC=20
> from you - I
> > think I've broken it :-(
> >
> > The GoodsReceivedControlled.php screen is labelled=20
> specifically for either
> a
> > serialised item or a controlled (and not serialised) item.=20
> The links for
> > entry on the GoodsReceived.php script are also labelled=20
> appropriately. The
> > not serialiased option refers to a batch qty which is=20
> defaulted to 1 for
> > serialiased items. The quantites are accumulated=20
> automatically from the
> > inputs made directly into the GoodsReceived.php=20
> $_SESSION['PO']->LineItems
> > variable.
> >
> > I'd like to think that the foundations for Serial and batch=20
> control are
> now
> > firmly in place and we can code up the other scripts.
> >
> > I REALLY hope you are still behind me on this and can live=20
> with my mods!
> >
> > Phil
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the=20
> market... Oracle 10g.
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market...=20
> Oracle 10g.=20
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>=20