Page 1 of 1

Splits function bug; Editing invoice prices

PostPosted: Mon Apr 28, 2014 8:00 am
by wlhowatt
I have two items:
1. Splits Function: The splits function is active allowing members to enter a quantity of less then one. The Disable Splits entirely for this source box is checked off. In the database the valid_order_increment and valid_split_increment have no values.

Editing invoice prices: We provide for local charities (i.e. food bank, schools, churches, etc.). One of our vendors will from time to time, just before distribution, decide to donate part of a charities order to them. The only way we have found to keep a record of the quantity of product we have received and at the same time remove the cost to the charity is to use the "Separate by item" function and selecting the "out of Stock" box. The problem with this is that it lists each multiple of the item selected as a separate items on the invoice for every member . For example, on our most recent order, the food bank ordered four cases of Strawberries which expanded the invoice somewhat. Another member ordered 35 cases. The expansion of their order was more problematic.

Is there a way to remove the cost of an item from a particular members invoice without using the "Separate by item"/"out of Stock" function?

Re: Splits function bug; Editing invoice prices

PostPosted: Thu May 01, 2014 8:26 pm
by support
To support donating to charities, I'd recommend doing it a different way: create a new user named something like "Donation to charity". When a user wants to donate an item, simply edit their order, delete the qty they want to donate, and then add that qty to the "donation" user.

This also has the added benefit of generating an invoice for the "donation" user, so you can keep track of how much and what is being donated. If you do it the way you described, with separate by item and out-of-stock, it would be difficult if not impossible to identify those items donated to charity later, in the system.

Does the above pose any problems for you, other than having an extra user account that doesn't belong to an actual club member? Does it seem like it would work?

Re: Splits function bug; Editing invoice prices

PostPosted: Sun May 04, 2014 6:52 pm
by wlhowatt
Our situation is a little different. The product is not being donated by the user to a charity, but by the vendor (source) to the user. So for this one user only, the product is free, while all the others pay regular price. One solution is to create two separate products in the database - one free and the other regular price. When the product is donated, edit the user's order, delete the regular price item and replace with the free item. This solution has a bit of overhead to create the free item and modify the user's order prior to generating invoices. We are mostly happy with our existing solution of changing the item to 'out of stock'. What we are really asking, is if the invoices should be displaying a separate line for each 'one' of an item. Once we use the separate by item function, if a user has purchased 10 units of an item, the invoice displays 10 rows of 1 units, rather than 1 row of 10 units.

Re: Splits function bug; Editing invoice prices

PostPosted: Sun May 04, 2014 9:15 pm
by support
Ah, I see. I've never heard of that situation, where a vendor donates to some users. I guess if you have charities on the Foodclub system though, that would make sense. I think you are probably the first to have charities / food banks actually using Foodclub.

Anyway, the way the "Separate by item" feature works is the way it's supposed to. It is meant for maximum flexibility, so if a case was partially out-of-stock, you can flag just certain quantities of the item as out-of-stock. That (partial out-of-stock) is the main use, but it also can be used for price changes on only some items, e.g. a vendor issues a partial credit for an item that was damaged, so you have to change the price to say 50% of it's normal price, just for a single quantity. (but leave all the rest of the quantities the normal price)

I know it can be very cumbersome when the Qty value is large, since it creates so many new rows in the table. That is just the trade-off for the flexibility.