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