web-erp-developers

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

[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

[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 <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

[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...>]

> 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

[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...>]

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] Controlled Items

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

Hi Jesse,

I am working on this .... 
I am finding it hard going though and not been able to put the time into it 
that I should have. I am working through the GoodsReceived.php and 
GoodsReceivedSerialised.php scripts with the changes in the DefinedPOClass 
required. I have started at the point the goods come in as the start of the 
business cycle. I am modifying it around a little - hope you will like it. 
Starting to get into it more now. This is quite a serious task.

So sorry I have not come back yet. Will need next weekend too before I have 
much to show. I will commit to CVS when I have any scipts that look like they 
work.

Phil

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

[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
>