>I have a vision of Mover ListBox and some action button, lke Define new region.
>But I'm not sure. I also not confident, do I need to create a file per customer or one big file to store all cusomers with their defined regions. My query from our main database should join this table and therefore idea of file per customer seems more easy to implement, but again, I'm not sure.
>
>This is a problem: make this algorithm as much generic, as possible to use one program for generating any kind of Custom Mortgage Report. The report itself, perhaps, should also be generated on the fly using predefined template.
>
>I'd like to exchange ideas and create a document first, before actual implementation.

I did something like this once in FPD2.6, but that'd be easier to do in VFP. I had a doctor's journal type of screen, where they had to pick opcodes of things they do (and they actually received money based on this). Now since some of the things were often grouped (they did the general examination with most of the things, then x-ray shot was always accompanied with assesment of the picture etc), I allowed for ad hoc groupings. I had a separate form to create these groups, and they'd first give a name to the group, then pick from a picklist or delete from the existing selection.

Once they wanted to do a group insert, I'd give them a group picklist, they'd pick one and I'd actually copy all the records from the group as if they'd picked them one by one themselves.

In your case, if there are not too many cities, the moverbox may be the proper choice; if there are just too many, maybe a combination of an autofill combo (or searchable single column grid) as a source, and a listbox as destination, would work. And I'd opt for a separate screen for creating the regions.

One thing to keep in mind - what's "user" in your case? The whole of all users within one customer entity, or any individual? The difference is in the way you should store these - if there are many users with their own regionalizations, you'd have to have a regions-per-user table as a parent to keep the region names, and city-per-region-per-user as a child table; if there's only one regionalization per customer, you need only the first one, and only add the region code into cities table.

(all this means I got nothing better to do on a Saturday afternoon :)