Jiwa

I've just got a request through, and I've asked for more information from the customer, but I thought I'd raise it here while I wait for said additional information.

Customer uses back-to-back sales orders (a custom version, not the standard one) for some (many?) of their sales.

For a particular new supplier, they will get different prices from their supplier, depending on who the end customer is.

And Purchase Orders need to reflect the debtor classification-specific pricing.

So their custom back-to-back solution needs further customising.

My initial thought was to use supplier warehouses, and add a warehouse for each (relevant) customer classification - it seems to have all the structure they'd need, and they're not really using supplier warehouses beyond the default.

The alternative would be to set up completely new structures, a path I'm reluctant to tread.

Is there a good reason to *not* use supplier warehouses, or a better idea that I've missed?

I would use the structure that's there as you are hardly trying to re-task it to something it's not, I get reluctant to bend something beyond that which it is intended for but in this case you really aren't doing that.

Adding additional structures/tables to support something custom usually involves the need to add a tab and grid somewhere and read in and write out data to a table and that can become a lot of work.

SBarnes wrote:the need to add a tab and grid somewhere and read in and write out data to a table and that can become a lot of work.

exactly why I want to avoid it...

pricerc wrote:My initial thought was to use supplier warehouses, and add a warehouse for each (relevant) customer classification - it seems to have all the structure they'd need, and they're not really using supplier warehouses beyond the default.

The alternative would be to set up completely new structures, a path I'm reluctant to tread.

Is there a good reason to *not* use supplier warehouses, or a better idea that I've missed?

That'll work - you can store the debtor ID in the SpareString1 field or similar.

A plugin can set the price, or if you're feeling energetic pass the customer id to the stored proc(s) for re-ordering and have them return it.

FWIW I've always been of the opinion that the price on a PO never has to be exact - the supplier will often inform you of price adjustments when they receive it, so the price on the PO can often just be temporary.

Mike.Sheen wrote:

pricerc wrote:My initial thought was to use supplier warehouses, and add a warehouse for each (relevant) customer classification - it seems to have all the structure they'd need, and they're not really using supplier warehouses beyond the default.

The alternative would be to set up completely new structures, a path I'm reluctant to tread.

Is there a good reason to *not* use supplier warehouses, or a better idea that I've missed?

That'll work - you can store the debtor ID in the SpareString1 field or similar.

A plugin can set the price, or if you're feeling energetic pass the customer id to the stored proc(s) for re-ordering and have them return it.

FWIW I've always been of the opinion that the price on a PO never has to be exact - the supplier will often inform you of price adjustments when they receive it, so the price on the PO can often just be temporary.

It looks like we're likely to go ahead with this approach.

Since the special prices are actually discounts of their sell price, I will also use a spare float to store the discount %, and add some plugin code to recalculate the price when the % is changed.

But that will probably be the easy part.

I just got the news that there will be up to 300,000 items involved, with an initial 30,000... importing that many through the standard inventory import process might take a while...

in IN_SupplierWarehouse, what is the purpose of SupplierCost2(and, by extension HomeCost2)? I've had a snoop in ILSpy, but don't see anything interesting.

And can I use it to store some (cost-related, as it happens) information? If the three spare floats aren't enough...

(I'm still undecided if I'll need it, but figure I've got a chance of getting an answer before close-of-play in Perth, and I can figure out whether I need it over the weekend...)

You can use those fields as I don't believe they are used in any calculations.

SBarnes wrote:You can use those fields as I don't believe they are used in any calculations.

Thanks.

Since these are a custom back-to-back order, the fields turn out to be a convenient place to put the debtor's sell price, which is mostly for debugging, and saves clicking around to find it.

(duplicate of comment on a related thread).

I know it's been almost two years since I originally posted this.

For anyone stumbling across this and wondering: yes, I did get it working. But there was a bit too much client-specific stuff in parts of it for me to just post the whole lot.

I have loaded the 'cleansed' source code into GitHub for anyone who is interested.

Just PM me with your GitHub user information and I'll invite you to the repo, which I have not made public (yet), a) because I'm not 100% sure it will work on a 'clean' installation of Jiwa, and b) because there are some minor bits missing, where I haven't got around to doing a 'generic' version of my customer's specific requirements.