Continuous Forms & Batch Processing

[phxbypdx]

Hey all -

I have a continuous form within my project that displays the inventory for a particular job. For each of the parts listed, I present the end user with "Quantity Ordered" & "Quantity Received" labels (these values are filled in previously). The application then presents the user with a (continuous) textbox named txtReturnQty.

The user enters a quantity to return for a particular line item. In the After_Update function, I process the return, and print the 'Part Returned' packing slip to be sent along to the vendor. This all works just fine.

What I want to do is give the users an option to return multiple parts to the same vendor. Currently, if a user returns 3 parts to Company ABC, 3 packing slips are printed (and the user has to enter the return quantity, tab out of the field to trigger after update, click Ok to confirm return, click Yes to print out part returned packing slip). I'd like to give them the option to mark a number of items for return, then batch process them & print 1 report. There are 2 problems I see:

First Problem - txtReturnQty is a textbox on a continuous form. You enter a value into one textbox, it enters the value into all textboxes. Can I make these independent of one another? Similar to Problem #2 - would solution be to add a field named "qtyReturned" to the table that defaults to 0, and is reset to 0 after print?

Second Problem - Batch processing generally doesn't work so well with databound continuous forms, correct? One option I've considered is to add a boolean field to the table (which is linked to our data file on the server) named "toprint". I could then have independent checkboxes on my form. If my txtReturnQty is independent, then on after_update, I check the box. On cmdPrint_Click, I then iterate through each of my rows, process data (changing qty received [aka qty on hand]) where toprint=true, etc etc?

Any other problems you can see? Any better solutions?

Thanks!

Scott

 

[MarkK]

Isn't a return simply an order with negative quantities? I think customers should be able to return items and buy different items on the same order number. All the math will work fine. Maybe you'll need to create a new product called 'Restocking Fee' that people buy when they return stuff.

 

[phxbypdx]

Isn't a return simply an order with negative quantities? I think customers should be able to return items and buy different items on the same order number. All the math will work fine. Maybe you'll need to create a new product called 'Restocking Fee' that people buy when they return stuff.

Appreciate the response, but perhaps you need some more information.

This isn't an application that is customer facing. It's an all encompassing application that manages payroll, inventory, reporting, and a slew of other items. And it's not quite as easy to change as your response might indicate.

Technicians place orders for parts needed to finish a job (mechanic shop), based on an estimate. This usually means there are dozens of parts from 3-5 vendors. On virtually every job, the inventory needs to be adjusted once the tech is actually inside the vehicle and sees whats broken, whats not, etc. To do this adjustment, the user either orders additional parts (when the estimate was short on parts), or returns already ordered parts (when the estimate was over). Often in a job, there are both additional parts ordered, and extra parts returned.

I'm simply trying to take the return parts process, extend it to include more efficient functionality. Rather than return 5 parts individually, I'd like to return 5 parts collectively. As I stated in OP, there are two problems I see with this, and I'm hoping to either resolve those problems, or find a better way.

Thx again,

Scott

 

[Kryst51]

Hey I had a similar question last week, check out this thread. Pay particular attention to the attachment by LPurvis at the end of the thread. I have implemented his idea into my db and it works wonderfully.

 

[MarkK]

To do this adjustment, the user either orders additional parts (when the estimate was short on parts), or returns already ordered parts (when the estimate was over). Often in a job, there are both additional parts ordered, and extra parts returned.

So you have a working order form? Why can't I order 3 filbert flanges and return 2 sludge pumps in the existing order form like this ...

3 Filbert Flange
-2 Sludge Pump

A return--fundamentally--is just a negative order!

 

[phxbypdx]

So you have a working order form? Why can't I order 3 filbert flanges and return 2 sludge pumps in the existing order form like this ...

3 Filbert Flange
-2 Sludge Pump

A return--fundamentally--is just a negative order!

Yes, I understand what a return is. I don't want to reinvent the wheel here. I already have a working return form that provides them with the core functionality they need. All I'm looking to do is to extend this functionality to make it slightly more user friendly.

 

[vbaInet]

Here's an idea I was playing with today. It allows an unbound textbox to have independent values in a continuous form. It probably also answers your second question.

See attached (saved in 2000 format).