web-erp-developers

[Web-erp-developers] Serial Stuff

[Phil D. <ph...@du...>]

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.

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

[Web-erp-developers] Serial Stuff

[Phil D. <ph...@du...>]

Jesse,

I committed ...

ConfirmDispatchControlled_Invoice.php
ConfirmDispatch_Invoice.php;
DeliveryDetails.php;
includes/DefineCartClass.php;
includes/DefineSerialItems.php;

to cvs tonight ... these contain the mods to effect serial (and batch) item 
control and specifying the serial numbers/ batches and quantity from each 
dispatched on an invoice. Not done the sql updates and inserts for invoices 
yet.

I stuffed the file input stuff - dont understand this - need your help.

Phil

[Web-erp-developers] Serial Stuff

[Phil D. <ph...@du...>]

Commited the ConfirmDispatch_Inovoice.php script with the sql updates in it to 
effect the serial items movements and update to StockSerialItems.

There's a disturbing number of other places to have batch/serial number 
selection facilities for:

StockAdjustments
StockTransfers
The new StockLocTransferReceive
CreditInvoice and SelectCreditItems
ReverseGRN

There is a lot of common code here too !

Then there's the StockCheck functionality, StockCounts and  comparison 
scripts...

Have I missed anything Jesse?

Phil

[Web-erp-developers] Serial Stuff

[Phil D. <ph...@du...>]

I have pretty well done this now except for ...

ReverseGRN.php and the stock check functionality creating stock adjustments 
for  counted items. I am not sure how to progress with this.

Any help with testing would be most appreciated.

Phil

[Web-erp-developers] Serial Stuff

[Phil D. <ph...@du...>]

Jesse,

The new InputSerialItems.php include file doesn't work quite right with some 
of the other scripts ...

ConfirmDispatchControlled_Invoice.php for one - and I suspect those where 
stock is going out that have the multi-select list box in them. 

Phil

[Web-erp-developers] Serial Stuff

[Phil D. <we...@pa...>]

Jesse,

Spent entire weekend on this lot ... still a couple more snags :-(

StockTransfers we have two DefineStockTransfer.php and
DefineStockTransfers.php used by the bulk and the single transfers.

The StockTransfer.php looks for stock in the location transferring to
NOT the location transferring from. You get a warning if there is
unsufficient stock at the location you are transferring to!!

Transfers are not effected ie location stock is not updated.

$title must be defined after session.inc but before header.inc

I have actually included this substitute _ function in config.php now as
a bit of a hack - but still $title must be defined using our _ function
after session.inc since config.php is included by session.inc

I have committed it to CVS but its buggy. May be something I have done.
Can you tell me why we are changing it? I was hoping to release a new
file. I'll keep banging away trying to figure it out.

Phil

Re: [Web-erp-developers] Serial Stuff

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

I'm glad it was far enough along to commit, that will make it much 
easier to work with now as changes/fixes are needed.
I'll try to look at the Credit_Invoice.php issue you pointed out - I 
remember having that happen on another one...

That StockTransfers confusion - I emailed to the list about it - I don't 
believe I broke them, but was a little confused as well. Since no one 
else has yet, I'll see what I can do to straighten out the various 
Transfer scripts.

The rest of what you mention here - I'm not real sure what you are 
talking about. If it's that I screwed up the location of $title some 
times, that's completely possible :)


jesse

Phil Daintree wrote:

>Jesse,
>
>Spent entire weekend on this lot ... still a couple more snags :-(
>
>StockTransfers we have two DefineStockTransfer.php and
>DefineStockTransfers.php used by the bulk and the single transfers.
>
>The StockTransfer.php looks for stock in the location transferring to
>NOT the location transferring from. You get a warning if there is
>unsufficient stock at the location you are transferring to!!
>
>Transfers are not effected ie location stock is not updated.
>
>$title must be defined after session.inc but before header.inc
>
>I have actually included this substitute _ function in config.php now as
>a bit of a hack - but still $title must be defined using our _ function
>after session.inc since config.php is included by session.inc
>
>I have committed it to CVS but its buggy. May be something I have done.
>Can you tell me why we are changing it? I was hoping to release a new
>file. I'll keep banging away trying to figure it out.
>
>Phil
>  
>

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