web-erp-developers — Discussion on development of webERP

[Web-erp-developers] Re: Warehouse Location Shipper

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

>
> Here are all of the scripts.  It can handle as many parts you want to ship.
>  I tested it up to 45 parts, worked great. It basically puts the parts in a
> Shipper table, then when the receiving person wants to receive them in they
> simply go to the receiver page.  the script PDFStockLocShipperHeader, needs
> to be in the includes.  Also, I have attached my index.diff so you can see
> where I added the links on the inventory page.
>


Hi Chris,

I have had a crack at the first part of your work and have added the Location 
Transfer creation script and the new table and the PDF report of the created 
transfer - albeit in a slightly different format - hope it serves the same 
function for you. I have added a few traps for things that I thought may go 
wrong, taken out references to mysql specific functions, tidied the code to 
be consisitent with the rest of the scripts.

I still have the hard bits to do to create the transfer on receipt of the 
shipment by the receiving location.

Many thanks for this contribution.

Phil

RE: [Web-erp-developers] Credit Items & Controlled Items

[jesse <je...@st...>]

gotcha. let me know when you do.

> -----Original Message-----
> From: web...@li...
> [mailto:web...@li...]On Behalf Of
> Daintree
> Sent: Saturday, April 24, 2004 16:44
> To: web...@li...
> Subject: Re: [Web-erp-developers] Credit Items & Controlled Items
>
>
> I wont have time this w/e to get into it. You'll have to bear with me a
> little.
>
> Phil
> ----- Original Message -----
> From: "jesse" <je...@st...>
> To: <web...@li...>
> Sent: Sunday, April 25, 2004 6:29 AM
> Subject: RE: [Web-erp-developers] Credit Items & Controlled Items
>
>
> > > But that doesn't really cover it for controlled. What about
> the sale of
> a
> > > quantity of oil that is in 10 drums - each drum containing 50 litres.
> > > Controlled but NOT serialised. The stock movement is for 500
> > > litres, we would
> > > only want one stockmove under your scenario? We would need a bundleID
> > > referenced to this stockmove for all 10 drums. One bundleID,
> > > would only cut it if it were possible to enter multiple items of the
> same
> > StockID on the
> > > same invoice - at the time of confirmDispatch_Invoice.php - maybe this
> is
> > > what you have in mind?
> >
> > No, not really - and I did not intend to ever have a StockId show up on
> more
> > than one invoice. If you ran into a case where it needed to be, then the
> > item probably needs to be Serialised somehow. This may be a
> scenario that
> > does not fit cleanly which we'll have to work on...
> > At first thought, I believe I might expect it to be a sort of
> manufactured
> > good - you pump the 10 drums of 50L out of your huge 1M litre vat to be
> > sold... and maybe they should be serialised - each drum gets an
> Id at some
> > point in the chain. So maybe a non-controlled StockMaster rec for 'Oil',
> > Units = Litres, then a Controlled, Serialised Assembly-type
> Item for '0 -
> 50
> > Litre Drum of Oil'. You sell that and when it is dispatched,
> for each Qty
> of
> > Barrel, the User will enter a SerialNum (or we can generate
> them) and real
> > Qty of Each item in the assemblies BOM. That will entail several changes
> to
> > actually accomodate it, of course.
> > Remember, my Controlled is aimed more at being a tracking number for a
> > StockMove and what ever it encompasses. and serialised is what
> allows you
> to
> > deal with individual item.
> >
> > How do you envision setting it up to sell it?
> >
> >
> > > One wouldn't want to be pre-allocating bundleids to orders before
> > > they are
> > > picked .... would you ? So shouldn't affect sales orders....
> > > should it? Same
> > > with PO - only really affects the delivery - GoodsReceived.php.
> >
> > Certainley not... they'd be allocated on the fly, say right before the
> > StockMove is added, if the option was on.
> >
> > > I will need to see it and play with it to fully get it I fear!!
> > > I am probably not that useful to bounce off coding issues on till
> > > I get into it. I do have views on the functionality we should code
> though,
> > > but only from a practical standpoint.
> >
> > It is wonderful to have firm opinions on how it needs to work - that
> > information is vital and, from what I've found, hard to obtain. And
> > hopefully what I sent you earlier will help... I'm interested
> to see what
> > you think...
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> > For a limited time only, get FREE Ground shipping on all orders of $35
> > or more. Hurry up and shop folks, this offer expires April 30th!
> > http://www.thinkgeek.com/freeshipping/?cpg=12297
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Credit Items & Controlled Items

[Daintree <p.d...@pa...>]

I wont have time this w/e to get into it. You'll have to bear with me a
little.

Phil
----- Original Message -----
From: "jesse" <je...@st...>
To: <web...@li...>
Sent: Sunday, April 25, 2004 6:29 AM
Subject: RE: [Web-erp-developers] Credit Items & Controlled Items


> > But that doesn't really cover it for controlled. What about the sale of
a
> > quantity of oil that is in 10 drums - each drum containing 50 litres.
> > Controlled but NOT serialised. The stock movement is for 500
> > litres, we would
> > only want one stockmove under your scenario? We would need a bundleID
> > referenced to this stockmove for all 10 drums. One bundleID,
> > would only cut it if it were possible to enter multiple items of the
same
> StockID on the
> > same invoice - at the time of confirmDispatch_Invoice.php - maybe this
is
> > what you have in mind?
>
> No, not really - and I did not intend to ever have a StockId show up on
more
> than one invoice. If you ran into a case where it needed to be, then the
> item probably needs to be Serialised somehow. This may be a scenario that
> does not fit cleanly which we'll have to work on...
> At first thought, I believe I might expect it to be a sort of manufactured
> good - you pump the 10 drums of 50L out of your huge 1M litre vat to be
> sold... and maybe they should be serialised - each drum gets an Id at some
> point in the chain. So maybe a non-controlled StockMaster rec for 'Oil',
> Units = Litres, then a Controlled, Serialised Assembly-type Item for '0 -
50
> Litre Drum of Oil'. You sell that and when it is dispatched, for each Qty
of
> Barrel, the User will enter a SerialNum (or we can generate them) and real
> Qty of Each item in the assemblies BOM. That will entail several changes
to
> actually accomodate it, of course.
> Remember, my Controlled is aimed more at being a tracking number for a
> StockMove and what ever it encompasses. and serialised is what allows you
to
> deal with individual item.
>
> How do you envision setting it up to sell it?
>
>
> > One wouldn't want to be pre-allocating bundleids to orders before
> > they are
> > picked .... would you ? So shouldn't affect sales orders....
> > should it? Same
> > with PO - only really affects the delivery - GoodsReceived.php.
>
> Certainley not... they'd be allocated on the fly, say right before the
> StockMove is added, if the option was on.
>
> > I will need to see it and play with it to fully get it I fear!!
> > I am probably not that useful to bounce off coding issues on till
> > I get into it. I do have views on the functionality we should code
though,
> > but only from a practical standpoint.
>
> It is wonderful to have firm opinions on how it needs to work - that
> information is vital and, from what I've found, hard to obtain. And
> hopefully what I sent you earlier will help... I'm interested to see what
> you think...
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

RE: [Web-erp-developers] Credit Items & Controlled Items

[jesse <je...@st...>]

> But that doesn't really cover it for controlled. What about the sale of a
> quantity of oil that is in 10 drums - each drum containing 50 litres.
> Controlled but NOT serialised. The stock movement is for 500
> litres, we would
> only want one stockmove under your scenario? We would need a bundleID
> referenced to this stockmove for all 10 drums. One bundleID,
> would only cut it if it were possible to enter multiple items of the same
StockID on the
> same invoice - at the time of confirmDispatch_Invoice.php - maybe this is
> what you have in mind?

No, not really - and I did not intend to ever have a StockId show up on more
than one invoice. If you ran into a case where it needed to be, then the
item probably needs to be Serialised somehow. This may be a scenario that
does not fit cleanly which we'll have to work on...
At first thought, I believe I might expect it to be a sort of manufactured
good - you pump the 10 drums of 50L out of your huge 1M litre vat to be
sold... and maybe they should be serialised - each drum gets an Id at some
point in the chain. So maybe a non-controlled StockMaster rec for 'Oil',
Units = Litres, then a Controlled, Serialised Assembly-type Item for '0 - 50
Litre Drum of Oil'. You sell that and when it is dispatched, for each Qty of
Barrel, the User will enter a SerialNum (or we can generate them) and real
Qty of Each item in the assemblies BOM. That will entail several changes to
actually accomodate it, of course.
Remember, my Controlled is aimed more at being a tracking number for a
StockMove and what ever it encompasses. and serialised is what allows you to
deal with individual item.

How do you envision setting it up to sell it?


> One wouldn't want to be pre-allocating bundleids to orders before
> they are
> picked .... would you ? So shouldn't affect sales orders....
> should it? Same
> with PO - only really affects the delivery - GoodsReceived.php.

Certainley not... they'd be allocated on the fly, say right before the
StockMove is added, if the option was on.

> I will need to see it and play with it to fully get it I fear!!
> I am probably not that useful to bounce off coding issues on till
> I get into it. I do have views on the functionality we should code though,
> but only from a practical standpoint.

It is wonderful to have firm opinions on how it needs to work - that
information is vital and, from what I've found, hard to obtain. And
hopefully what I sent you earlier will help... I'm interested to see what
you think...

Re: [Web-erp-developers] Credit Items & Controlled Items

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

On Saturday 24 April 2004 12:24, jesse wrote:
> Hum... let me remind you how I've put this together since it wasn't quite
> like you had originally thought of doing it, and some of your answers seem
> to be refering to your way rather than how I've coded it....from the top,
>
> A StockMaster record can be Controlled. If it is Controlled, it can also be
> Serialised, but does not have to be. If it is Serialised, a StockModule is
> required (that has no bearing on this discussion except that it's part of
> my changes). Lastly, the *only* inventory table considered to be 1-to-1 is
> StockItems - a StockMoves record could have a Qty of 1, thus being 1-to-1,
> but just as easily could have Qty 0.1 (g when StockMaster.Units in kg) or
> 100 (Cell Phones w/ SerialNos). Further, Serialised item Qtys are always
> Integers - no decimal places. This has just made me remember I need to make
> sure I enforce that everywhere!
>
> Controlled means that anytime a StockMove is being done, the User is
> required to enter a Bundle(Id) for it - some sort of Id that can be used to
> generally refer to the full Qty involved in that StockMove. That, so far,
> entails POs, SOs, Stock Transfers, Stock Adjustments, Credits, ReverseGRNs,
> and anything else I run upon that I missed.
>

But that doesn't really cover it for controlled. What about the sale of a 
quantity of oil that is in 10 drums - each drum containing 50 litres. 
Controlled but NOT serialised. The stock movement is for 500 litres, we would 
only want one stockmove under your scenario? We would need a bundleID 
referenced to this stockmove for all 10 drums. One bundleID, would only cut 
it if it were possible to enter multiple items of the same StockID on the 
same invoice - at the time of confirmDispatch_Invoice.php - maybe this is 
what you have in mind?

One wouldn't want to be pre-allocating bundleids to orders before they are 
picked .... would you ? So shouldn't affect sales orders.... should it? Same 
with PO - only really affects the delivery - GoodsReceived.php.


I will need to see it and play with it to fully get it I fear!!

I am probably not that useful to bounce off coding issues on till I get into 
it. I do have views on the functionality we should code though, but only from 
a practical standpoint.

Phil

RE: [Web-erp-developers] Credit Items & Controlled Items

[jesse <je...@st...>]

Hum... let me remind you how I've put this together since it wasn't quite
like you had originally thought of doing it, and some of your answers seem
to be refering to your way rather than how I've coded it....from the top,

A StockMaster record can be Controlled. If it is Controlled, it can also be
Serialised, but does not have to be. If it is Serialised, a StockModule is
required (that has no bearing on this discussion except that it's part of my
changes). Lastly, the *only* inventory table considered to be 1-to-1 is
StockItems - a StockMoves record could have a Qty of 1, thus being 1-to-1,
but just as easily could have Qty 0.1 (g when StockMaster.Units in kg) or
100 (Cell Phones w/ SerialNos). Further, Serialised item Qtys are always
Integers - no decimal places. This has just made me remember I need to make
sure I enforce that everywhere!

Controlled means that anytime a StockMove is being done, the User is
required to enter a Bundle(Id) for it - some sort of Id that can be used to
generally refer to the full Qty involved in that StockMove. That, so far,
entails POs, SOs, Stock Transfers, Stock Adjustments, Credits, ReverseGRNs,
and anything else I run upon that I missed.

Serialised means that you have a single item with a single tracking number
(through a little code you could fairly easily code and decode single
SerialNos from multiple ones if necessary - I'll explain later). B/c of some
of the things we are talking about, these items can be moved between
StockMoves outside their original Qty (someone returning 1 item out of 10
sold to them, selling 5 of 1000 purchased). StockItemMoves tracks those with
the ItemId, and the old and new StockMoveNo. From that, you basically can
look at all the previous StockMoves a item was part of if you need to.

based on that, some answers below... and maybe check out the other email
again...
> > if Controlled, allow:
> > 1) Enter/Select 1 to X Bundles based on the StockId and the Quantities
> from each bundle being Returned. Qty's being returned must be <=the Qty of
> the Original Bundle.
>
> Do you mean Sum(Qty) of the individiual bundles must be == Qty of
> the total
> stock move, or is perhaps accumulated into == that quantity for the stock
> move record?

I mean that you can Credit X, Y, and Z qty of items of out 3 different
Bundles so long as X,Y,& Z are all <= the Qty of each Bundle they refer to.
Or do it w/ (2)

One thing - to Credit, I am adding an option that allows/forces you to pick
whether or not you are going to strictly Credit (verify each item) or
loosely credit (the geezums) - that is option (2) here....

> > 2) Additionally, you may Credit any Quantity without referencing an
> existing Bundle
> > if Serialised: Items are treated like they are being brought in on a PO
> where Item details must be verified and the total number of Items
> must match
> the Qty being Credited.
>
> Could the quantity be accumulated from the bundles rather than
> entering the
> quantity and then trying to tie it up.

Certainley... though probably by defaulting the value of the Qty field the
the full Qty :)

> > There's nothing to keep the user from using a previous BundleId, but I
> won't be prepopulating that. The alternative would be to treat each
> 'sub-line' (ie, all 5 Bundles of a StockId) as a full line, complete with
> it's own BundleId and StockMove.
>
> That kinda what I was thinking originally - but your method of keeping
> bundle movements table separately I thought was better.

I may actually make it possible to control (or not) BundleIds so that you
(ok, the code) could grab a new one and force it to be used when doing a
move. I guess that would be an option...

Re: [Web-erp-developers] Credit Items & Controlled Items

[Daintree <p.d...@pa...>]

Jesse,

I knew it wouldn't be easy .... but when you put it like that, its does
sound particularly daunting!!
I would say "Geezums" - almost covers it, but still seems somehow
inadequate.

> So with Credits, we have these scenarios:
>
> If Not Controlled, allow:
> 1) Credit any Quantity for each StockId (like it is now)
>
> if Controlled, allow:
> 1) Enter/Select 1 to X Bundles based on the StockId and the Quantities
from each bundle being Returned. Qty's being returned must be <= the Qty of
the Original Bundle.

Do you mean Sum(Qty) of the individiual bundles must be == Qty of the total
stock move, or is perhaps accumulated into == that quantity for the stock
move record?

> if Serialised: Quantity of Serialised Items entered must match Qty being
returned per bundle and be verified as available for return (current
StockMove type = SalesOrder [more?]) and as having come from the bundle it
is trying to be returned against.


If serialised the qty per bundle is 1 n'est pas? With scenarios we have been
looking at, do the bundleids need to be verified against existing sales
bundleids? This would be good but I think in practise flexibility is
necessary.

>
> 2) Additionally, you may Credit any Quantity without referencing an
existing Bundle
> if Serialised: Items are treated like they are being brought in on a PO
where Item details must be verified and the total number of Items must match
the Qty being Credited.

Could the quantity be accumulated from the bundles rather than entering the
quantity and then trying to tie it up.

>
>
> For both Controlled Scenarios, the User will still be prompted to enter a
BundleId to identify this entire transaction that will, >in essence, roll up
everything being returned using a single, new BundleId and a single
StockMove (per StockId).

Do we really need the BundleID in the stockmoves table anymore ? I thought
you were using the stockmoveID as the reference for the bundles on the
movement.


> There's nothing to keep the user from using a previous BundleId, but I
won't be prepopulating that. The alternative would be to treat each
'sub-line' (ie, all 5 Bundles of a StockId) as a full line, complete with
it's own BundleId and StockMove.

That kinda what I was thinking originally - but your method of keeping
bundle movements table separately I thought was better.

> In Addition, I'll probably move to restructure the Credit Scripts such
that the base is something like SelectCreditItems and CreditInvoice simply
provides an easy method to prepopulate the values on it rather than
replicating the whole thing with just a slightly different selection
criteria.... then selecting Bundles, etc. would flow into it the same way.

That makes sense.

> ... and I thought I was almost done yesterday ;)
>
> I still think there should be some other way to Credit a Customer account
without telling someone to 'Credit X dummy StockItems', but I may not be
looking at it objectively enough.
>

RE: [Web-erp-developers] Credit Items & Controlled Items

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

Geezums. This could make it difficult to make numbers match up.

So with Credits, we have these scenarios:

If Not Controlled, allow:
1) Credit any Quantity for each StockId (like it is now)

if Controlled, allow:
1) Enter/Select 1 to X Bundles based on the StockId and the Quantities =
from each bundle being Returned. Qty's being returned must be <=3D the =
Qty of the Original Bundle.
	if Serialised: Quantity of Serialised Items entered must match Qty =
being returned per bundle and be verified as available for return =
(current StockMove type =3D SalesOrder [more?]) and as having come from =
the bundle it is trying to be returned against.

2) Additionally, you may Credit any Quantity without referencing an =
existing Bundle
	if Serialised: Items are treated like they are being brought in on a PO =
where Item details must be verified and the total number of Items must =
match the Qty being Credited.


For both Controlled Scenarios, the User will still be prompted to enter =
a BundleId to identify this entire transaction that will, in essence, =
roll up everything being returned using a single, new BundleId and a =
single StockMove (per StockId). There's nothing to keep the user from =
using a previous BundleId, but I won't be prepopulating that. The =
alternative would be to treat each 'sub-line' (ie, all 5 Bundles of a =
StockId) as a full line, complete with it's own BundleId and StockMove.
In Addition, I'll probably move to restructure the Credit Scripts such =
that the base is something like SelectCreditItems and CreditInvoice =
simply provides an easy method to prepopulate the values on it rather =
than replicating the whole thing with just a slightly different =
selection criteria.... then selecting Bundles, etc. would flow into it =
the same way.

... and I thought I was almost done yesterday ;)

I still think there should be some other way to Credit a Customer =
account without telling someone to 'Credit X dummy StockItems', but I =
may not be looking at it objectively enough.

Let me know what you guys think about the above scenarios.


jesse

> -----Original Message-----
> From: Phil Daintree [mailto:ph...@du...]
> Sent: Thursday, April 22, 2004 23:10
> To: web...@li...
> Subject: Re: [Web-erp-developers] Credit Items & Controlled Items
>=20
>=20
> >
> > > When a customer makes a product which has wider appeal=20
> and you wish to
> > > market it, it would be great to be able to book it in as=20
> a credit note
> > > knocking off against what he owes us.
> > I don't understand the correlation between these exactly...help?
>=20
> I'll tell you a story .... are you sitting comfortably?
>=20
> We are in the business of selling toys, specialising in=20
> puzzles. We sell
> puzzles internationally and one customer has developed a=20
> really cool puzzle
> that he wholesales locally in Poland. There is a great market=20
> for these in
> the US and we decide to import them. We sell 100k per month=20
> of puzzles to
> the Polish agent and we are bringing in 2k worth of these=20
> things from him.
> They are electronic puzzles with a worth of 1k each - we need=20
> to keep track
> of the serial numbers coming in and sold we'll knock the=20
> amount we owe him
> off our account.
>=20
> How would we deal with this in the accounting?
>=20
> Perhaps we'd be better to set them up as a supplier if its on=20
> going business
> so we can plan for deliveires and arrivals of product.=20
> However, in the short
> term we could just book the product in against a credit note to their
> debtors account - provided there is some facility to enter in=20
> serial numbers
> for the product arriving, that has never been sold to them.
>=20
> >
> > > There are two credit note scripts one is to credit an invoice
> > > - the details
> > > of the invoice can be retrieved with serial numbered items as
> > > they were when
> > > invoiced. I still think there needs to be scope to change
> > > these though, in
> > > case the customer returns other than the originally invoiced
> > > items or a
> > > mistake was made when invoicing/pciking the right items.
> > > The other credit note SelectCreditItems.php should allow free
> > > form entry of the bundleIDs .... I rekon.
> > Ok, I know them. I figured w/ CreditInvoice I would force=20
> everything to be
> kosher - Items must still exist and must be from this Invoice. For
> Controlled&Serialised, this could often be a real pain to use=20
> if you wanted
> to return Items that originated in more than one Bundle (b/c=20
> it would not
> let you).
>=20
> Even the CreditInvoice needs to allow changing of BundleIDs -=20
> the wrong
> BundleID was entered at the time of invoice or they sold the=20
> actual product
> of the invoice and are returning the same part but different=20
> bundleIDs.
>=20
>=20
> >
> > I figured SelectCreditItems would be what allowed you to=20
> select several
> Bundles &/or SerialNos (like your free-form entry method).=20
> Still then -
> should the Credits track w/ the Original BundleId or a new one? I was
> thinking of using the Credit BundleID as something like an=20
> RMA# (Return
> Merchandise Authorization, in case you aren't familiar with=20
> the U.S. version
> of it) to track Credits back in.
>=20
>=20
> This would be different for each return no? I am thinking=20
> that whilst it
> should be possible to have returns against a specific invoice strictly
> enforced, in practise I think not, flexibility with what is=20
> entered for the
> bundleid is important I think.
>=20
> > OK :) So how do we make the distinction or draw the line?=20
> Should we have a
> new 'Credit Whatever You Want' script? >OR... this may do=20
> it... What if it
> simply depended on the Credit Note Type - 'Returned To Store' requires
> strict validation, >'Written Off' doesn't.
>=20
> I don't think you can push the strict validation bit too far=20
> - flexibility
> is required in practise.
>=20
> I rekon all the time - I'm from the North West of England - I=20
> do all sorts
> of strang things :-)
>=20
> Phil
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=3D12297
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>=20

Re: [Web-erp-developers] Credit Items & Controlled Items

[Danie B. <br...@na...>]

Hi Phil, Jesse

Once again sorry for jumping in, If you remember my discussion earlier
about someone making a mistake on the credit notes and needing a journal
to correct the customers accounts, would this not be what you need ? If
I understand accounting correct, every time you do something out of the
ordinary it should be reflected in a  journal. The journal would also
help with the take-on of customer totals without invoices. ( Also you
can not credit a negative amount. i.e correct a credit note mistake. )
And for the same reasons I also vote Yes to be able to return goods
without invoice. ( The invoice might not be there, from the start. )

Kind Regards
Danie Brink 

On Fri, 2004-04-23 at 05:10, Phil Daintree wrote:

> >
> > > When a customer makes a product which has wider appeal and you wish to
> > > market it, it would be great to be able to book it in as a credit note
> > > knocking off against what he owes us.
> > I don't understand the correlation between these exactly...help?
> 
> I'll tell you a story .... are you sitting comfortably?
> 
> We are in the business of selling toys, specialising in puzzles. We sell
> puzzles internationally and one customer has developed a really cool puzzle
> that he wholesales locally in Poland. There is a great market for these in
> the US and we decide to import them. We sell 100k per month of puzzles to
> the Polish agent and we are bringing in 2k worth of these things from him.
> They are electronic puzzles with a worth of 1k each - we need to keep track
> of the serial numbers coming in and sold we'll knock the amount we owe him
> off our account.
> 
> How would we deal with this in the accounting?
> 
> Perhaps we'd be better to set them up as a supplier if its on going business
> so we can plan for deliveires and arrivals of product. However, in the short
> term we could just book the product in against a credit note to their
> debtors account - provided there is some facility to enter in serial numbers
> for the product arriving, that has never been sold to them.
> 
> >
> > > There are two credit note scripts one is to credit an invoice
> > > - the details
> > > of the invoice can be retrieved with serial numbered items as
> > > they were when
> > > invoiced. I still think there needs to be scope to change
> > > these though, in
> > > case the customer returns other than the originally invoiced
> > > items or a
> > > mistake was made when invoicing/pciking the right items.
> > > The other credit note SelectCreditItems.php should allow free
> > > form entry of the bundleIDs .... I rekon.
> > Ok, I know them. I figured w/ CreditInvoice I would force everything to be
> kosher - Items must still exist and must be from this Invoice. For
> Controlled&Serialised, this could often be a real pain to use if you wanted
> to return Items that originated in more than one Bundle (b/c it would not
> let you).
> 
> Even the CreditInvoice needs to allow changing of BundleIDs - the wrong
> BundleID was entered at the time of invoice or they sold the actual product
> of the invoice and are returning the same part but different bundleIDs.
> 
> 
> >
> > I figured SelectCreditItems would be what allowed you to select several
> Bundles &/or SerialNos (like your free-form entry method). Still then -
> should the Credits track w/ the Original BundleId or a new one? I was
> thinking of using the Credit BundleID as something like an RMA# (Return
> Merchandise Authorization, in case you aren't familiar with the U.S. version
> of it) to track Credits back in.
> 
> 
> This would be different for each return no? I am thinking that whilst it
> should be possible to have returns against a specific invoice strictly
> enforced, in practise I think not, flexibility with what is entered for the
> bundleid is important I think.
> 
> > OK :) So how do we make the distinction or draw the line? Should we have a
> new 'Credit Whatever You Want' script? >OR... this may do it... What if it
> simply depended on the Credit Note Type - 'Returned To Store' requires
> strict validation, >'Written Off' doesn't.
> 
> I don't think you can push the strict validation bit too far - flexibility
> is required in practise.
> 
> I rekon all the time - I'm from the North West of England - I do all sorts
> of strang things :-)
> 
> Phil
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 

Re: [Web-erp-developers] Credit Items & Controlled Items

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

>
> > When a customer makes a product which has wider appeal and you wish to
> > market it, it would be great to be able to book it in as a credit note
> > knocking off against what he owes us.
> I don't understand the correlation between these exactly...help?

I'll tell you a story .... are you sitting comfortably?

We are in the business of selling toys, specialising in puzzles. We sell
puzzles internationally and one customer has developed a really cool puzzle
that he wholesales locally in Poland. There is a great market for these in
the US and we decide to import them. We sell 100k per month of puzzles to
the Polish agent and we are bringing in 2k worth of these things from him.
They are electronic puzzles with a worth of 1k each - we need to keep track
of the serial numbers coming in and sold we'll knock the amount we owe him
off our account.

How would we deal with this in the accounting?

Perhaps we'd be better to set them up as a supplier if its on going business
so we can plan for deliveires and arrivals of product. However, in the short
term we could just book the product in against a credit note to their
debtors account - provided there is some facility to enter in serial numbers
for the product arriving, that has never been sold to them.

>
> > There are two credit note scripts one is to credit an invoice
> > - the details
> > of the invoice can be retrieved with serial numbered items as
> > they were when
> > invoiced. I still think there needs to be scope to change
> > these though, in
> > case the customer returns other than the originally invoiced
> > items or a
> > mistake was made when invoicing/pciking the right items.
> > The other credit note SelectCreditItems.php should allow free
> > form entry of the bundleIDs .... I rekon.
> Ok, I know them. I figured w/ CreditInvoice I would force everything to be
kosher - Items must still exist and must be from this Invoice. For
Controlled&Serialised, this could often be a real pain to use if you wanted
to return Items that originated in more than one Bundle (b/c it would not
let you).

Even the CreditInvoice needs to allow changing of BundleIDs - the wrong
BundleID was entered at the time of invoice or they sold the actual product
of the invoice and are returning the same part but different bundleIDs.


>
> I figured SelectCreditItems would be what allowed you to select several
Bundles &/or SerialNos (like your free-form entry method). Still then -
should the Credits track w/ the Original BundleId or a new one? I was
thinking of using the Credit BundleID as something like an RMA# (Return
Merchandise Authorization, in case you aren't familiar with the U.S. version
of it) to track Credits back in.


This would be different for each return no? I am thinking that whilst it
should be possible to have returns against a specific invoice strictly
enforced, in practise I think not, flexibility with what is entered for the
bundleid is important I think.

> OK :) So how do we make the distinction or draw the line? Should we have a
new 'Credit Whatever You Want' script? >OR... this may do it... What if it
simply depended on the Credit Note Type - 'Returned To Store' requires
strict validation, >'Written Off' doesn't.

I don't think you can push the strict validation bit too far - flexibility
is required in practise.

I rekon all the time - I'm from the North West of England - I do all sorts
of strang things :-)

Phil

RE: [Web-erp-developers] Credit Items & Controlled Items

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

> Its a good point, I can see an argument both ways. The=20
> arguments against I
> see are:
> When a customer's account and stock movements are purged two=20
> years later -
> the warranty is 5 years ....
Ok, haven't considered at all that one would purge records - I'll try to =
keep that in mind...to an extent.

> When a customer makes a product which has wider appeal and you wish to
> market it, it would be great to be able to book it in as a credit note
> knocking off against what he owes us.
I don't understand the correlation between these exactly...help?

> There are two credit note scripts one is to credit an invoice=20
> - the details
> of the invoice can be retrieved with serial numbered items as=20
> they were when
> invoiced. I still think there needs to be scope to change=20
> these though, in
> case the customer returns other than the originally invoiced=20
> items or a
> mistake was made when invoicing/pciking the right items.
> The other credit note SelectCreditItems.php should allow free=20
> form entry of the bundleIDs .... I rekon.
Ok, I know them. I figured w/ CreditInvoice I would force everything to =
be kosher - Items must still exist and must be from this Invoice. For =
Controlled&Serialised, this could often be a real pain to use if you =
wanted to return Items that originated in more than one Bundle (b/c it =
would not let you).

I figured SelectCreditItems would be what allowed you to select several =
Bundles &/or SerialNos (like your free-form entry method). Still then - =
should the Credits track w/ the Original BundleId or a new one? I was =
thinking of using the Credit BundleID as something like an RMA# (Return =
Merchandise Authorization, in case you aren't familiar with the U.S. =
version of it) to track Credits back in.
=20
> I vote yes.
OK :) So how do we make the distinction or draw the line? Should we have =
a new 'Credit Whatever You Want' script? OR... this may do it... What if =
it simply depended on the Credit Note Type - 'Returned To Store' =
requires strict validation, 'Written Off' doesn't.=20
There's a lot of numbers that get pushed by this, and the accounting =
(biz accounting, not numbers) side is not my strong suite, so you may =
need to correct me a bit.

> form entry of the bundleIDs .... I rekon.
I thought only us folk from the SouthEastern U.S. reckon'd! :)

Re: [Web-erp-developers] Credit Items & Controlled Items

[Daintree <p.d...@pa...>]

> I'm down to finishing up my Serialised Item work and just need to get the
Credit_invoice and SelectCreditItems finalized. I've realized that currently
one seems to be allowed to Credit back items which were never purchased -
this does not seem right. In validating Serialised Items, I've made sure
they exist and can be used (ie, you can't sell an item you've already
sold... unless it has been returned to stock, like through a Credit). I
planned to also validate Serialised items returned on a CreditNote - must
exist, must have been sold to the Customer being credited, and must still be
attached to a SalesOrder.
> Thoughts on that? I'd be inclined to simply not allow Credits for more
Items than have been purchased.


Its a good point, I can see an argument both ways. The arguments against I
see are:
When a customer's account and stock movements are purged two years later -
the warranty is 5 years ....
When a customer makes a product which has wider appeal and you wish to
market it, it would be great to be able to book it in as a credit note
knocking off against what he owes us.


>
> In tracking Controlled Items I force a BundleId to be entered for the
goods as they are Received via a PO and as they sold via a SO. One
consideration, which I believe will be made/changed in a second round on
Serialised additions is forcing unique BundleIds (ie, auto selecting them
through a new method rather than prompting the User to enter them). What I
am wondering is the best way to track Credited, Controlled Items coming back
in. I have a feeling that they should be tracked using the BundleId they
went out on a SO with.
>
> If that is the case, I now also need to force a Bundle to be selected when
Controlled Items are to be credited, which again requires that only items
that have been sold can be Credited.

There are two credit note scripts one is to credit an invoice - the details
of the invoice can be retrieved with serial numbered items as they were when
invoiced. I still think there needs to be scope to change these though, in
case the customer returns other than the originally invoiced items or a
mistake was made when invoicing/pciking the right items.

The other credit note SelectCreditItems.php should allow free form entry of
the bundleIDs .... I rekon.


That brings some changes since it is not as easy to return 5 (each) of 10
different StockIds from 3 different Bundles. Further, when using
SelectCreditItems, I'll need to create StockMoves for every affected Bundle.
Using Credit_Invoice this is taken care of since it is restricted to one
Invoice, thus 1 LineItem per StockId, so also just 1 BundleId.
>
> So, I guess the question is just whether you should be able to Credit
items that were never sold....
>

I vote yes.

Phil

[Web-erp-developers] Credit Items & Controlled Items

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

I'm down to finishing up my Serialised Item work and just need to get =
the Credit_invoice and SelectCreditItems finalized. I've realized that =
currently one seems to be allowed to Credit back items which were never =
purchased - this does not seem right. In validating Serialised Items, =
I've made sure they exist and can be used (ie, you can't sell an item =
you've already sold... unless it has been returned to stock, like =
through a Credit). I planned to also validate Serialised items returned =
on a CreditNote - must exist, must have been sold to the Customer being =
credited, and must still be attached to a SalesOrder.=20
Thoughts on that? I'd be inclined to simply not allow Credits for more =
Items than have been purchased.

In tracking Controlled Items I force a BundleId to be entered for the =
goods as they are Received via a PO and as they sold via a SO. One =
consideration, which I believe will be made/changed in a second round on =
Serialised additions is forcing unique BundleIds (ie, auto selecting =
them through a new method rather than prompting the User to enter them). =
What I am wondering is the best way to track Credited, Controlled Items =
coming back in. I have a feeling that they should be tracked using the =
BundleId they went out on a SO with.

If that is the case, I now also need to force a Bundle to be selected =
when Controlled Items are to be credited, which again requires that only =
items that have been sold can be Credited. That brings some changes =
since it is not as easy to return 5 (each) of 10 different StockIds from =
3 different Bundles. Further, when using SelectCreditItems, I'll need to =
create StockMoves for every affected Bundle. Using Credit_Invoice this =
is taken care of since it is restricted to one Invoice, thus 1 LineItem =
per StockId, so also just 1 BundleId.

So, I guess the question is just whether you should be able to Credit =
items that were never sold....


jesse

Re: [Web-erp-developers] Re: Warehouse Location Shipper

[Daintree <p.d...@pa...>]

Not it didn't work! But my email server defangs any scripts with active
content ie java. I'll get there.

There's a bit of work in this lot - many thanks!

Phil
----- Original Message -----
From: "Chris Bice" <cb...@en...>
To: "WebERP Developers" <web...@li...>
Sent: Thursday, April 22, 2004 1:07 AM
Subject: Re: [Web-erp-developers] Re: Warehouse Location Shipper


> Sorry about that. I had thrown some of the mysql functions in there as
> I was testing, and forgot to transform them over. As for the variable
> items, I'm not used to programming that way, but its no big deal, ill
> try and make sure I can get my code to conform to the Web-ERP Style.
> With That Said, did you test out the scripts??  And IF So did you find
> any error's in them? Im curious to see if it works on someone else's
> system.
>
> Chris
>
> On Wed, 2004-04-21 at 05:21, Phil Daintree wrote:
> > > Here are all of the scripts.  It can handle as many parts you want to
ship.
> > >  I tested it up to 45 parts, worked great. It basically puts the parts
in a
> > > Shipper table, then when the receiving person wants to receive them in
they
> > > simply go to the receiver page.  the script PDFStockLocShipperHeader,
needs
> > > to be in the includes.  Also, I have attached my index.diff so you can
see
> > > where I added the links on the inventory page.
> > >
> > > If you need anything let me know.
> > >
> > > Chris
> >
> > Thanks Chris,
> >
> > This is great, thanks so much for feeding your work back to the project.
> >
> > I started work on the StockLocShipper.php report and input form - there
a
> > couple of really minor points that I would encourage you to ignore, but
if
> > you wanted to make my life even easier :-) .....
> >
> > - I try to avoid any dependence on Java ... at all
> >
> > - I have been religious in adherence to the database abstraction
functions in
> > ConnectDB.inc - ie there are no mysql specific function calls (at all)
in any
> > scripts except ConnectDB.inc eg Last insert ID and mysql err etc. It
would a
> > shame to compromise now.
> >
> > - I try to limit nasty messages to the debug user - ie only system
> > administrators. The variable $debug is set to 1 if the user is an
> > administrator in header.inc or session.inc
> >
> > - This stuff is really picky now and absolutely irrelavent to anything
much
> > but .... PHP offers a lot of flexibility in its syntax (some see this as
a
> > weakness of the language) - your syntax may well be better than that
used in
> > existing scripts, but I have adopted a slightly different style in a
number
> > of areas:
> >
> > 1. code blocks - my { always follows the statement for which the block
is
> > associated with rather than being a line down. else always appears as
> > } else {
> >
> > 2. I try to be careful with indenting, to ensure I don't get into
closing }
> > errors.
> >
> > 3. I always contacenate $_POST['IndexName'] variables inside strings
rather
> > than have them parsed out by PHP. eg.
> >
> > $StringVble = "This string says $_POST['SomePostedVble'] is one possible
way
> > to write it";
> >
> > However, I write this as:
> >
> > $StringVble = "This string says " . $_POST['SomePostedVble'] . " is
another
> > possible way to write it";
> >
> > 4. I always quote the name of the index of variables eg.
> >
> > $_POST[SomeVariableIndexName]
> >
> > I write as :
> >
> > $_POST['SomeVariableIndexName']
> >
> > Of course none of this  matters really - I guess I have just got used to
these
> > peculiarities and having all the scripts written this way so far, it
makes
> > sense to me to continue in the same way.
> >
> > I am working through the scripts to make them conform to these
conventions.
> > Hope you don't mind.
> >
> > Thanks again for your contributions, please keep em coming!
> >
> > Phil
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Re: Warehouse Location Shipper

[Chris B. <cb...@en...>]

Sorry about that. I had thrown some of the mysql functions in there as 
I was testing, and forgot to transform them over. As for the variable
items, I'm not used to programming that way, but its no big deal, ill
try and make sure I can get my code to conform to the Web-ERP Style. 
With That Said, did you test out the scripts??  And IF So did you find
any error's in them? Im curious to see if it works on someone else's
system.

Chris

On Wed, 2004-04-21 at 05:21, Phil Daintree wrote:
> > Here are all of the scripts.  It can handle as many parts you want to ship.
> >  I tested it up to 45 parts, worked great. It basically puts the parts in a
> > Shipper table, then when the receiving person wants to receive them in they
> > simply go to the receiver page.  the script PDFStockLocShipperHeader, needs
> > to be in the includes.  Also, I have attached my index.diff so you can see
> > where I added the links on the inventory page.
> >
> > If you need anything let me know.
> >
> > Chris
> 
> Thanks Chris,
> 
> This is great, thanks so much for feeding your work back to the project.
> 
> I started work on the StockLocShipper.php report and input form - there a 
> couple of really minor points that I would encourage you to ignore, but if 
> you wanted to make my life even easier :-) .....
> 
> - I try to avoid any dependence on Java ... at all
> 
> - I have been religious in adherence to the database abstraction functions in 
> ConnectDB.inc - ie there are no mysql specific function calls (at all) in any 
> scripts except ConnectDB.inc eg Last insert ID and mysql err etc. It would a 
> shame to compromise now.
> 
> - I try to limit nasty messages to the debug user - ie only system 
> administrators. The variable $debug is set to 1 if the user is an 
> administrator in header.inc or session.inc
> 
> - This stuff is really picky now and absolutely irrelavent to anything much 
> but .... PHP offers a lot of flexibility in its syntax (some see this as a 
> weakness of the language) - your syntax may well be better than that used in 
> existing scripts, but I have adopted a slightly different style in a number 
> of areas:
> 
> 1. code blocks - my { always follows the statement for which the block is 
> associated with rather than being a line down. else always appears as
> } else {
> 
> 2. I try to be careful with indenting, to ensure I don't get into closing } 
> errors. 
> 
> 3. I always contacenate $_POST['IndexName'] variables inside strings rather 
> than have them parsed out by PHP. eg. 
> 
> $StringVble = "This string says $_POST['SomePostedVble'] is one possible way 
> to write it";
> 
> However, I write this as:
> 
> $StringVble = "This string says " . $_POST['SomePostedVble'] . " is another 
> possible way to write it";
> 
> 4. I always quote the name of the index of variables eg.
> 
> $_POST[SomeVariableIndexName]
> 
> I write as :
> 
> $_POST['SomeVariableIndexName']
> 
> Of course none of this  matters really - I guess I have just got used to these 
> peculiarities and having all the scripts written this way so far, it makes 
> sense to me to continue in the same way.
> 
> I am working through the scripts to make them conform to these conventions. 
> Hope you don't mind.
> 
> Thanks again for your contributions, please keep em coming!
> 
> Phil
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Re: Purchse Orders

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

Are you referring to the fields in GLTrans ?

Contract Reference will refer to the contract that a GLTrans relates to - all 
of this is yet to be coded.

The ShipmentRef has not been used in GLTrans we can actually drop this field I 
think? I created a new table with all shipment charges against it to avoid 
any dependence of shipment costing on GL integration of AP.

Shipments are about costing product received from a distant supplier where the 
costs of frieght, duty, cartage, receiving etc need to be included and 
apportioned between the items on the shipment. (currently only on the basis 
of value)

Contract costing is about accumulating the costs of a contract to compare 
against the contract quotation .... all only a twinkle at this stage.

Phil

On Wednesday 21 April 2004 22:44, Danie Brink wrote:
> Hi Phil
>
> I need a bit of help please...
>
> I would like to know how the Shipment Reference is used, as well as how
> the Contract Reference is used. This one confuses me.
>
> This is where I am with the supplier order manual at this stage.
>
> Kind Regards
> br...@b2...

[Web-erp-developers] Re: Purchse Orders

[Danie B. <br...@na...>]

Hi Phil

I need a bit of help please...

I would like to know how the Shipment Reference is used, as well as how
the Contract Reference is used. This one confuses me. 

This is where I am with the supplier order manual at this stage.

Kind Regards
br...@b2...

[Web-erp-developers] Re: Warehouse Location Shipper

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

> Here are all of the scripts.  It can handle as many parts you want to ship.
>  I tested it up to 45 parts, worked great. It basically puts the parts in a
> Shipper table, then when the receiving person wants to receive them in they
> simply go to the receiver page.  the script PDFStockLocShipperHeader, needs
> to be in the includes.  Also, I have attached my index.diff so you can see
> where I added the links on the inventory page.
>
> If you need anything let me know.
>
> Chris

Thanks Chris,

This is great, thanks so much for feeding your work back to the project.

I started work on the StockLocShipper.php report and input form - there a 
couple of really minor points that I would encourage you to ignore, but if 
you wanted to make my life even easier :-) .....

- I try to avoid any dependence on Java ... at all

- I have been religious in adherence to the database abstraction functions in 
ConnectDB.inc - ie there are no mysql specific function calls (at all) in any 
scripts except ConnectDB.inc eg Last insert ID and mysql err etc. It would a 
shame to compromise now.

- I try to limit nasty messages to the debug user - ie only system 
administrators. The variable $debug is set to 1 if the user is an 
administrator in header.inc or session.inc

- This stuff is really picky now and absolutely irrelavent to anything much 
but .... PHP offers a lot of flexibility in its syntax (some see this as a 
weakness of the language) - your syntax may well be better than that used in 
existing scripts, but I have adopted a slightly different style in a number 
of areas:

1. code blocks - my { always follows the statement for which the block is 
associated with rather than being a line down. else always appears as
} else {

2. I try to be careful with indenting, to ensure I don't get into closing } 
errors. 

3. I always contacenate $_POST['IndexName'] variables inside strings rather 
than have them parsed out by PHP. eg. 

$StringVble = "This string says $_POST['SomePostedVble'] is one possible way 
to write it";

However, I write this as:

$StringVble = "This string says " . $_POST['SomePostedVble'] . " is another 
possible way to write it";

4. I always quote the name of the index of variables eg.

$_POST[SomeVariableIndexName]

I write as :

$_POST['SomeVariableIndexName']

Of course none of this  matters really - I guess I have just got used to these 
peculiarities and having all the scripts written this way so far, it makes 
sense to me to continue in the same way.

I am working through the scripts to make them conform to these conventions. 
Hope you don't mind.

Thanks again for your contributions, please keep em coming!

Phil

Re: [Web-erp-developers] Re: Desktop manuals

[Danie B. <br...@na...>]

Hi Phil

In response to your section on :
Why WebERP and not commercial ?
and your (2c worth) I agree with you, the answer I was looking for (for
this manual), was covered in the first section (About the creator(s) of
WebERP). I will have a look and see where I can use your other section's
persuasive arguments (Why WebERP and not commercial ?). Maybe, on the
site as a reason on why, also maybe an introductory news letter,
promotional material, etc.

Thanks again for the input, I did add the other section to the foreword.
I will probably, now after speaking, to the printers still produce extra
manuals but they will now be published in a single book. Costs are
inhibitive, cost of a single manual amount to about R80 about US$ 11,
while producing about a hundred will cost about R19 about US$ 2.7
exchange 7:1. However manual will be bound in white sleeve with WebERP
Image and name on cover and spline, glue bound, size A4. However at this
time I will have to produce one at a time and therefore R80 per manual
and therefore all in one.

I will let you know when that is done.

Updated book is available as usual @
http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.doc
http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.pdf
http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.sxw

Kind Regards
Danie Brink br...@b2...


On Mon, 2004-04-19 at 12:06, Phil Daintree wrote: 

> > However while experimenting, I created a credit note with a random
> > value. Then proceeded to allocate against customer invoices. Some money
> > remained. This got me thinking WHAT IF the operator accidentally type a
> > digit wrong or add one, then what ? I tested this scenario and found
> > that there was no way to correct/modify this and also you can not credit
> > a negative value, it refused. ( An option would be to allow negative
> > credit values for overcharge credit type.) However it got me thinking
> > that you might be able to correct this with a Journal entry, however I
> > have not tested this because I am still busy with the Supplier Order
> > Desktop Manual. As you pointed out this is not possible. Everything else
> > I have tried to mess up I managed to correct.
> >
> > What is your opinion on this scenario ? How can this problem be fixed ?
> > Should it be fixed, if not how do you balance the books then ? It is the
> > books I am concerned with, both the company's accounts and the customer
> > account.
> 
> You can fix it with an invoice of a dummy item. The dummy item being of a 
> stock category that posts to the right place to reverse the credit - this is 
> a little messy and perhaps a journal facility might be good for opening 
> balances too.
> 
> >
> > Revised Manuals Available here again. If you are happy with it please
> > put it on Sourceforge
> > Replace the Login Screen in the document if you would like to.
> > http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.doc
> > http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.pdf
> > http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.sxw
> >
> 
> Below is my contribution to your manual as requested - hope it's ok.
> 
> About the creator(s) of WebERP.
> WebERP is the product of countless hours of effort, most of the time an 
> enjoyable tussle with logic for its own sake. As a CA and businessman with a 
> perverse lust for internal process improvement and a belief in the power of 
> software to drive that improvement, webERP has become a conduit for my views 
> on how the basic business processes should be preformed. I have enjoyed the 
> input from others in this regard and the evolution of both the system and my 
> views throughout its development to date.
> Having gone through this, largely for the challenge and pleasure of doing so, 
> the irony is that without businesses taking advantage of webERP, the whole 
> exercise has been a massive waste of time. The very focus of process 
> improvement is of course to eliminate waste!
> 
> This is hopefully the beginning of the journey as more and more like-minded 
> individuals see the value of webERP and their contributions (of code) further 
> enhance the functionality and  appeal of webERP.
> 
> Phil Daintree – BA(Hons) CA
> 
> Why WebERP and not commercial ?
> 
> Why not a commercial product or an alternative like Compiére? 
> 
> (This is complex - I am not sure if this should be in the manual really but 
> this is my 2c - actually this may be more a $1 worth.)
> 
> There are good reasons to adopt a commercial system. Many years of development 
> by professionals, the backing of possibly an international company and 
> someone to blame if it all goes pear shaped – to name a few. It is much 
> easier to use commercial systems that have accumulated some credibility in 
> the eyes of the accounting profession. Also, commercial companies are more 
> likely to have the necessary marketing spend to put the product in front of 
> would be users and promote its features and benefits. There is no doubt that 
> marketing influences perceptions and that perceptions are particularly 
> important in mission critical software. To repeat the cliché:
> 
> “No one was ever fired for buying IBM/HP”
> 
> There are also some persuasive reasons against commercial software. Having 
> purchased a license to run a commercial system, there is no one else to turn 
> to when it doesn't do exactly what the business needs it to do. Many 
> businesses have experienced this now. This puts the business in a very 
> difficult situation, it is beholden to the software company:
> 1.The software vendor is the only company where modifications can be made. 
> 2.The software vendor is the only company that can truly support the product 
> and know the inner workings of the program. They effectively become a 
> monopoly as soon as the software is sold. Ongoing support contracts can 
> become very expensive.
> 3.Taking legal action against the software company for breach of contract 
> would limit the businesses ability to continue using the software with 
> effective support.
> 4.When things go wrong there is no other company to turn to, to resolve 
> problem.The business is stuck with the software vendor and the alternative, 
> to change the system completely is often prohibitively expensive.
> 
> The only way around these problems is to have access to the source code of the 
> software. This is not traditionally available in commercial software 
> licensing arrangements.
> 
> Further, there are powerful arguments for open source software. The eyes and 
> scrutiny of the code by so many programmers results in higher quality code 
> and software that is consequently more reliable. Bugs reports are actively 
> encouraged and can be repaired by anyone. In use by a business, web-erp 
> invites the business to create scripts to exactly meet its needs rather than 
> try to fit within the confines of the square hole of closed source software. 
> The business is truly free to make the software work precisely according to 
> its own rules, not those of the commercial software vendor. 
> Finally, open source software has the advantage of being very cost effective!
> There are now a number of other open source systems. Where webERP is strong 
> relative to other open source accounting systems is:
> 1.The accessibility of the PHP code, all written in plain english. Abstraction 
> which does not add to the efficiency of the code has been actively avoided. 
> Use of only the one programming language - PHP, reduces the knowledge 
> necessary to be able to effect meaningful modifications. PHP is widely 
> regarded as one of the more straightforward languages to program with.
> 2.Minimal requirements of the client computers. Only a web-browser and pdf 
> reader are required.
> 3.The basic infrastructure is cheap, PHP and MySQL can run on virtually all 
> computers and are themselves open source software.
> 4.Since it is web-based it offers low cost wide area networking. Using SSL – 
> it offers a very low cost and efficient VPN.
> 
> Phil
> 
> 
> 
> --
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 

Re: [Web-erp-developers] case sensitive table problem mysql linuxwindows

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

Phil,

Is it not important to have the best price performance hosting platform
(linux) be very compatible with world most used platform (windows)?

Some notes about this issue in the documentation is a good start.

With best regards,
Dick Stins
----- Original Message -----
From: "Phil Daintree" <ph...@du...>
To: <web...@li...>
Sent: Monday, April 19, 2004 1:48 AM
Subject: Re: [Web-erp-developers] case sensitive table problem mysql
linuxwindows


> Its only a snag when dumping a windows db and re-instating a *nix based=
 -
> case sensitive - db. Windows install works fine, *nix install works fin=
e.
> Only when windows install taken to *nix.
>
> I think a note in install.txt may confuse things a bit?
>
> Phil
> ----- Original Message -----
> From: "jesse" <je...@st...>
> To: <web...@li...>
> Sent: Monday, April 19, 2004 10:06 AM
> Subject: RE: [Web-erp-developers] case sensitive table problem mysql
> linuxwindows
>
>
> > Dick, please take a look at this:
> > http://dev.mysql.com/doc/mysql/en/Name_case_sensitivity.html
> >
> > The proper fix for this problem is listed there using the 'mysqld.
> lower_case_table_names' config option. I would say either 0 or 2 would
work.
> > This also alleviates changing all table names which would be a nightm=
are
> in the code, for upgrades, etc.
> >
> > Going forward the install docs need to reflect this caveat for window=
s
> mysql systems.
> >
> > how's that sound?
> >
> > -----Original Message-----
> > From: web...@li...
> [mailto:web...@li...]On Behalf Of Sti=
ns,
> Dick
> > Sent: Sunday, April 18, 2004 17:22
> > To: web...@li...
> > Subject: Re: [Web-erp-developers] case sensitive table problem mysql
> linuxwindows
> >
> >
> > Danie,
> >
> > Thanks for the tip, but the mysql windows server is storing all table=
s
in
> lowercase.
> > Dumping with quotes results still in lowercase table names (ofcourse
> between quotes).
> >
> > I still think that it is the best to transform all tablenames to
> lowercase. This will give 100% full compatibility at this issue between
> web-erp at windows an web-erp at linux.
> >
> > With best regards,
> >
> > Dick Stins
> > ----- Original Message -----
> > From: Danie Brink
> > To: Phil Daintree
> > Sent: Saturday, April 17, 2004 2:37 PM
> > Subject: Re: [Web-erp-developers] case sensitive table problem mysql
> linuxwindows
> >
> >
> > Hi Dick,
> > I have found this problem myself with MySQL , but found that by
exporting
> with quotes it solved the problem, you should ask mysqldump to to do th=
at,
> if I remember correctly you use the -Q command line option.
> >
> > This might help or Not as I have never tried working with the windows
> version.
> >
> > On Sat, 2004-04-17 at 10:19, Stins, Dick wrote:
> > Dear all,
> >
> > I have a very annoying problem.
> >
> > mysql at windows converts all table names to lower case.
> >
> > When you create a dump of the database, it's also converted to lowerc=
ase
> table names.
> >
> > When you import this at linux, it works fine except that all scripts
> expect case sensitive table names and are returning errors.
> >
> > After some study, I concluded that using only lowercase table names i=
n
> scripts and in the mysql database is the best solution to keep the mysq=
l
> data exchangeble between those platforms for all web-erp users.
> >
> > Another option is to create a seperate script to rename the tables at
the
> unix platform back to case sensitive, but that crashed the mysql server
> completely (bug).
> >
> > I suspect that this might be caused by circular references in the
foreign
> key definitions, but I am not sure about that.
> >
> > With best regards,
> >
> > Dick Stins
> >
> > p.s. I have a rename table script available for lowercase to uppercas=
e
> conversion, when someone is interested.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&opk
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[Web-erp-developers] Re: Desktop manuals

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

> However while experimenting, I created a credit note with a random
> value. Then proceeded to allocate against customer invoices. Some money
> remained. This got me thinking WHAT IF the operator accidentally type a
> digit wrong or add one, then what ? I tested this scenario and found
> that there was no way to correct/modify this and also you can not credit
> a negative value, it refused. ( An option would be to allow negative
> credit values for overcharge credit type.) However it got me thinking
> that you might be able to correct this with a Journal entry, however I
> have not tested this because I am still busy with the Supplier Order
> Desktop Manual. As you pointed out this is not possible. Everything else
> I have tried to mess up I managed to correct.
>
> What is your opinion on this scenario ? How can this problem be fixed ?
> Should it be fixed, if not how do you balance the books then ? It is the
> books I am concerned with, both the company's accounts and the customer
> account.

You can fix it with an invoice of a dummy item. The dummy item being of a=20
stock category that posts to the right place to reverse the credit - this i=
s=20
a little messy and perhaps a journal facility might be good for opening=20
balances too.

>
> Revised Manuals Available here again. If you are happy with it please
> put it on Sourceforge
> Replace the Login Screen in the document if you would like to.
> http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.doc
> http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.pdf
> http://www.b2brus.co.za/downloads/WebERPMan/DesktopManual.sxw
>

Below is my contribution to your manual as requested - hope it's ok.

About the creator(s) of WebERP.
WebERP is the product of countless hours of effort, most of the time an=20
enjoyable tussle with logic for its own sake. As a CA and businessman with =
a=20
perverse lust for internal process improvement and a belief in the power of=
=20
software to drive that improvement, webERP has become a conduit for my view=
s=20
on how the basic business processes should be preformed. I have enjoyed the=
=20
input from others in this regard and the evolution of both the system and m=
y=20
views throughout its development to date.
Having gone through this, largely for the challenge and pleasure of doing s=
o,=20
the irony is that without businesses taking advantage of webERP, the whole=
=20
exercise has been a massive waste of time. The very focus of process=20
improvement is of course to eliminate waste!

This is hopefully the beginning of the journey as more and more like-minded=
=20
individuals see the value of webERP and their contributions (of code) furth=
er=20
enhance the functionality and  appeal of webERP.

Phil Daintree =E2=80=93 BA(Hons) CA

Why WebERP and not commercial ?

Why not a commercial product or an alternative like Compi=C3=A9re?=20

(This is complex - I am not sure if this should be in the manual really but=
=20
this is my 2c - actually this may be more a $1 worth.)

There are good reasons to adopt a commercial system. Many years of developm=
ent=20
by professionals, the backing of possibly an international company and=20
someone to blame if it all goes pear shaped =E2=80=93 to name a few. It is =
much=20
easier to use commercial systems that have accumulated some credibility in=
=20
the eyes of the accounting profession. Also, commercial companies are more=
=20
likely to have the necessary marketing spend to put the product in front of=
=20
would be users and promote its features and benefits. There is no doubt tha=
t=20
marketing influences perceptions and that perceptions are particularly=20
important in mission critical software. To repeat the clich=C3=A9:

=E2=80=9CNo one was ever fired for buying IBM/HP=E2=80=9D

There are also some persuasive reasons against commercial software. Having=
=20
purchased a license to run a commercial system, there is no one else to tur=
n=20
to when it doesn't do exactly what the business needs it to do. Many=20
businesses have experienced this now. This puts the business in a very=20
difficult situation, it is beholden to the software company:
1.The software vendor is the only company where modifications can be made.=
=20
2.The software vendor is the only company that can truly support the produc=
t=20
and know the inner workings of the program. They effectively become a=20
monopoly as soon as the software is sold. Ongoing support contracts can=20
become very expensive.
3.Taking legal action against the software company for breach of contract=20
would limit the businesses ability to continue using the software with=20
effective support.
4.When things go wrong there is no other company to turn to, to resolve=20
problem.The business is stuck with the software vendor and the alternative,=
=20
to change the system completely is often prohibitively expensive.

The only way around these problems is to have access to the source code of =
the=20
software. This is not traditionally available in commercial software=20
licensing arrangements.

=46urther, there are powerful arguments for open source software. The eyes =
and=20
scrutiny of the code by so many programmers results in higher quality code=
=20
and software that is consequently more reliable. Bugs reports are actively=
=20
encouraged and can be repaired by anyone. In use by a business, web-erp=20
invites the business to create scripts to exactly meet its needs rather tha=
n=20
try to fit within the confines of the square hole of closed source software=
=2E=20
The business is truly free to make the software work precisely according to=
=20
its own rules, not those of the commercial software vendor.=20
=46inally, open source software has the advantage of being very cost effect=
ive!
There are now a number of other open source systems. Where webERP is strong=
=20
relative to other open source accounting systems is:
1.The accessibility of the PHP code, all written in plain english. Abstract=
ion=20
which does not add to the efficiency of the code has been actively avoided.=
=20
Use of only the one programming language - PHP, reduces the knowledge=20
necessary to be able to effect meaningful modifications. PHP is widely=20
regarded as one of the more straightforward languages to program with.
2.Minimal requirements of the client computers. Only a web-browser and pdf=
=20
reader are required.
3.The basic infrastructure is cheap, PHP and MySQL can run on virtually all=
=20
computers and are themselves open source software.
4.Since it is web-based it offers low cost wide area networking. Using SSL =
=E2=80=93=20
it offers a very low cost and efficient VPN.

Phil

Re: [Web-erp-developers] case sensitive table problem mysql linuxwindows

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

Its only a snag when dumping a windows db and re-instating a *nix based -
case sensitive - db. Windows install works fine, *nix install works fine.
Only when windows install taken to *nix.

I think a note in install.txt may confuse things a bit?

Phil
----- Original Message -----
From: "jesse" <je...@st...>
To: <web...@li...>
Sent: Monday, April 19, 2004 10:06 AM
Subject: RE: [Web-erp-developers] case sensitive table problem mysql
linuxwindows


> Dick, please take a look at this:
> http://dev.mysql.com/doc/mysql/en/Name_case_sensitivity.html
>
> The proper fix for this problem is listed there using the 'mysqld.
lower_case_table_names' config option. I would say either 0 or 2 would work.
> This also alleviates changing all table names which would be a nightmare
in the code, for upgrades, etc.
>
> Going forward the install docs need to reflect this caveat for windows
mysql systems.
>
> how's that sound?
>
> -----Original Message-----
> From: web...@li...
[mailto:web...@li...]On Behalf Of Stins,
Dick
> Sent: Sunday, April 18, 2004 17:22
> To: web...@li...
> Subject: Re: [Web-erp-developers] case sensitive table problem mysql
linuxwindows
>
>
> Danie,
>
> Thanks for the tip, but the mysql windows server is storing all tables in
lowercase.
> Dumping with quotes results still in lowercase table names (ofcourse
between quotes).
>
> I still think that it is the best to transform all tablenames to
lowercase. This will give 100% full compatibility at this issue between
web-erp at windows an web-erp at linux.
>
> With best regards,
>
> Dick Stins
> ----- Original Message -----
> From: Danie Brink
> To: Phil Daintree
> Sent: Saturday, April 17, 2004 2:37 PM
> Subject: Re: [Web-erp-developers] case sensitive table problem mysql
linuxwindows
>
>
> Hi Dick,
> I have found this problem myself with MySQL , but found that by exporting
with quotes it solved the problem, you should ask mysqldump to to do that,
if I remember correctly you use the -Q command line option.
>
> This might help or Not as I have never tried working with the windows
version.
>
> On Sat, 2004-04-17 at 10:19, Stins, Dick wrote:
> Dear all,
>
> I have a very annoying problem.
>
> mysql at windows converts all table names to lower case.
>
> When you create a dump of the database, it's also converted to lowercase
table names.
>
> When you import this at linux, it works fine except that all scripts
expect case sensitive table names and are returning errors.
>
> After some study, I concluded that using only lowercase table names in
scripts and in the mysql database is the best solution to keep the mysql
data exchangeble between those platforms for all web-erp users.
>
> Another option is to create a seperate script to rename the tables at the
unix platform back to case sensitive, but that crashed the mysql server
completely (bug).
>
> I suspect that this might be caused by circular references in the foreign
key definitions, but I am not sure about that.
>
> With best regards,
>
> Dick Stins
>
> p.s. I have a rename table script available for lowercase to uppercase
conversion, when someone is interested.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&opk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] case sensitive table problem mysql linuxwindows

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

Jesse,

Thanks, but I read also the user comments. This scared me off. And it is
dependend of the configuration of mysql, so you keep the problem when the
mysql database is configured with different parameters.

Changing the table names is independent of everything and solves this iss=
ue
for ever (although I was surprised that mysql uses lowercase. Oracle uses
standard uppercase, but this will be compatible with unquoted tablenames =
in
create table scripts.).

For changing the scripts, I hoped that you are a wizard with unix shell
scripting and convert the table names to lowercase within a few minutes f=
or
all scripts.

For renaming tablenames in the database is a little harder. I think we ne=
ed
to do:
- backup the database
- dump the data separately from the create table scripts.
- Rename the table names in this script with the unix shell scripting tri=
ck.
- drop all tables
- create tables (with lowercase names) like a new installation (complete
empty tables + constraints)
- insert the data

With best regards,

Dick Stins

p.s. I tried the the rename table statement, but that crashed the complet=
e
mysql server process.

----- Original Message -----
From: "jesse" <je...@st...>
To: <web...@li...>
Sent: Monday, April 19, 2004 12:06 AM
Subject: RE: [Web-erp-developers] case sensitive table problem mysql
linuxwindows


Dick, please take a look at this:
http://dev.mysql.com/doc/mysql/en/Name_case_sensitivity.html

The proper fix for this problem is listed there using the 'mysqld.
lower_case_table_names' config option. I would say either 0 or 2 would wo=
rk.
This also alleviates changing all table names which would be a nightmare =
in
the code, for upgrades, etc.

Going forward the install docs need to reflect this caveat for windows my=
sql
systems.

how's that sound?

-----Original Message-----
From: web...@li...
[mailto:web...@li...]On Behalf Of Stins=
,
Dick
Sent: Sunday, April 18, 2004 17:22
To: web...@li...
Subject: Re: [Web-erp-developers] case sensitive table problem mysql
linuxwindows


Danie,

Thanks for the tip, but the mysql windows server is storing all tables in
lowercase.
Dumping with quotes results still in lowercase table names (ofcourse betw=
een
quotes).

I still think that it is the best to transform all tablenames to lowercas=
e.
This will give 100% full compatibility at this issue between web-erp at
windows an web-erp at linux.

With best regards,

Dick Stins
----- Original Message -----
From: Danie Brink
To: Phil Daintree
Sent: Saturday, April 17, 2004 2:37 PM
Subject: Re: [Web-erp-developers] case sensitive table problem mysql
linuxwindows


Hi Dick,
I have found this problem myself with MySQL , but found that by exporting
with quotes it solved the problem, you should ask mysqldump to to do that=
,
if I remember correctly you use the -Q command line option.

This might help or Not as I have never tried working with the windows
version.

On Sat, 2004-04-17 at 10:19, Stins, Dick wrote:
Dear all,

I have a very annoying problem.

mysql at windows converts all table names to lower case.

When you create a dump of the database, it's also converted to lowercase
table names.

When you import this at linux, it works fine except that all scripts expe=
ct
case sensitive table names and are returning errors.

After some study, I concluded that using only lowercase table names in
scripts and in the mysql database is the best solution to keep the mysql
data exchangeble between those platforms for all web-erp users.

Another option is to create a seperate script to rename the tables at the
unix platform back to case sensitive, but that crashed the mysql server
completely (bug).

I suspect that this might be caused by circular references in the foreign
key definitions, but I am not sure about that.

With best regards,

Dick Stins

p.s. I have a rename table script available for lowercase to uppercase
conversion, when someone is interested.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

RE: [Web-erp-developers] case sensitive table problem mysql linuxwindows

[jesse <je...@st...>]

Dick, please take a look at this:
http://dev.mysql.com/doc/mysql/en/Name_case_sensitivity.html

The proper fix for this problem is listed there using the 'mysqld. =
lower_case_table_names' config option. I would say either 0 or 2 would =
work.=20
This also alleviates changing all table names which would be a nightmare =
in the code, for upgrades, etc.

Going forward the install docs need to reflect this caveat for windows =
mysql systems.

how's that sound?

-----Original Message-----
From: web...@li... =
[mailto:web...@li...]On Behalf Of =
Stins, Dick
Sent: Sunday, April 18, 2004 17:22
To: web...@li...
Subject: Re: [Web-erp-developers] case sensitive table problem mysql =
linuxwindows


Danie,

Thanks for the tip, but the mysql windows server is storing all tables =
in lowercase.=20
Dumping with quotes results still in lowercase table names (ofcourse =
between quotes).

I still think that it is the best to transform all tablenames to =
lowercase. This will give 100% full compatibility at this issue between =
web-erp at windows an web-erp at linux.

With best regards,

Dick Stins
----- Original Message -----=20
From: Danie Brink=20
To: Phil Daintree=20
Sent: Saturday, April 17, 2004 2:37 PM
Subject: Re: [Web-erp-developers] case sensitive table problem mysql =
linuxwindows


Hi Dick,
I have found this problem myself with MySQL , but found that by =
exporting with quotes it solved the problem, you should ask mysqldump to =
to do that, if I remember correctly you use the -Q command line option.

This might help or Not as I have never tried working with the windows =
version.

On Sat, 2004-04-17 at 10:19, Stins, Dick wrote:=20
Dear all,
=20
I have a very annoying problem.
=20
mysql at windows converts all table names to lower case.
=20
When you create a dump of the database, it's also converted to lowercase =
table names.
=20
When you import this at linux, it works fine except that all scripts =
expect case sensitive table names and are returning errors.
=20
After some study, I concluded that using only lowercase table names in =
scripts and in the mysql database is the best solution to keep the mysql =
data exchangeble between those platforms for all web-erp users.
=20
Another option is to create a seperate script to rename the tables at =
the unix platform back to case sensitive, but that crashed the mysql =
server completely (bug).=20
=20
I suspect that this might be caused by circular references in the =
foreign key definitions, but I am not sure about that.
=20
With best regards,
=20
Dick Stins
=20
p.s. I have a rename table script available for lowercase to uppercase =
conversion, when someone is interested.=20

Re: [Web-erp-developers] Re: Desktop manuals

[Daintree <p.d...@pa...>]

I mean JESSE - I definetly got that now :-)

----- Original Message -----
From: "jesse" <je...@st...>
To: <web...@li...>
Sent: Monday, April 19, 2004 7:33 AM
Subject: RE: [Web-erp-developers] Re: Desktop manuals


> couple things -
> Jesse, not Jessie. Jesse is also literally missing an eye, which I
sometimes use as a spelling reminder, and a little pun that I get a kick out
of, so you can too
> Jesse is he, not she.
>
> that is all :)
>
> > -----Original Message-----
> > From: web...@li...
> > [mailto:web...@li...]On Behalf Of Phil
> > Daintree
> > Sent: Sunday, April 18, 2004 04:38
> > To: web...@li...
> > Subject: [Web-erp-developers] Re: Desktop manuals
> >
> >
> > Hi Danie,
> >
> > > How do I check out a specific version from CVS and then run a diff on
> > > that version. Specifically I am making the changes against 2.8 and
want
> > > to do a diff against that so I can send the diffs to you as I go
along.
> > > It should be easier to review than everything at once.
> >
> > The CVS always contains the very latest scripts I always update
> > as I make any
> > mods. Don't forget that Jessie is working on a substanital effort
> > to give us
> > serialised stock, which she is about to send me scripts for. So
> > if you have
> > major mods may be best to hold off till I get Jessie's stuff
> > committed to the
> > CVS.
> >
> >
> > Phil
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&opk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>