Re: [Web-erp-developers] Serial Stuff

[Stins, D. <DR...@Zi...>]

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

> 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 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 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 using those
> conventions. Consistency of application of these conventions throughout
are
> important to me. I have spelled these conventions out elsewhere in the
> developers list. Perhaps for a younger mind this is probably a non-issue.
>
> I have worked through the GoodsReceivedControlled Code and notice that
much of
> the code for PO items received is actually in the StockModules - since it
> will only ever be used from the goods received script I prefer all code
> relating to that function to be in that one place so the 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 re-used or re-used
> only once then the cost in terms of abstraction is too much (for me). I
> concede that this is wrong and contrary to accepted wisdom - but I just
can't
> see it.
Phil,
When you use good names for intuitive functions/classes/method, then it
should improve readability. Having not all code in the same script will
improve quality, because only the changed code can raise new errors. So by
splitting scripts, you will have a big advantage for the maintance, since
you reduce the creation of errors and this will also reduce the testing
effors.
You allready accepted the concept of splitting scripts for readability,
since you use include files, several scripts instead of one and only one
script for web-erp.
When you want an overall controlling coding standard, then 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 might attract
high qualified PEAR developers and prevents you and  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 now. To keep
control over this project, you need a higher abstraction level and
concentrate at business functions and component based development instead of
bothering about coding details.
Setting up new ideas for anarchitecture with a data ayer, 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)

I am personnally more worried about bugs in WEB-ERP then different coding
layout styles.

with best regards,
Dick
>
> The StockModules Stuff .....
>
> I see what you are doing allowing for alternative 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 stockcategory
table
> and perhaps the parameters for validation would be better held together
with
> other like information in that table, rather than hard coded and adding
> another level of abstraction for those of us who suffer with them. I have
not
> coded up this but see no problem in doing so. Where specific additional
> inserts for new tables peculiar to the business are required this will
always
> require modification of the code - I like to keep the code 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 the SerialItems
> array and validates it before adding it - just as I did with the other
> scripts using arrays of multiple variables.
>
> I have the GoodsReceivedControlled.php working for manual 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 of serial nos.
I
> don't have the file input stuff going, this again looks a bit tough for
me.
> I've left it in - just commented it out - it needs some TLC from you - I
> think I've broken it :-(
>
> The GoodsReceivedControlled.php screen is labelled specifically for either
a
> serialised item or a controlled (and not serialised) item. The links for
> entry on the GoodsReceived.php script are also labelled appropriately. The
> not serialiased option refers to a batch qty which is defaulted to 1 for
> serialiased items. The quantites are accumulated automatically from the
> inputs made directly into the GoodsReceived.php $_SESSION['PO']->LineItems
> variable.
>
> I'd like to think that the foundations for Serial and batch 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 with my mods!
>
> Phil
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers