You're right, I can see two different use cases for how a user would like the import to function. Controlling it from an option in the openbravo.properties is a great idea.
The current method: import=replace
Where the current stock is more or less "overwritten" by the import. Any exising stock from other categories is made to disapear. I could see a use case where the categories are more like product years or something like that. The old category "2011 stock" would be made to disapear when the "2012 stock" was imported.
The proposed method: import=merge
Where the current stock is updated where product ids match and left alone where there is no corresponding record in the import file. This method is a bit more intuitive from an end user perspective. The first step is to prevent the Openbravo import from deliting the old categories.
Setting up a multi-category export and import capability could be the next phase in development. I like what you're thinking about the iterative looping on the ERP side. We'd need to think about how the JMS message would look. Would we use one message for each category or one message with all categories? I've noticed that the Openbravo import will only grab the latest record from the queue in situations where there is more than one record. So we'll need to fix the import process to handle multiple queue entries if we do the export of multiple categories as individual messages.
New Year's Eve in Paris... how wonderful! You'll have a great time. I've never been, but it should be a great sight to see the fireworks at the Tower. I'll have to get you out to Minnesota so we can hook up - but not when it's this cold. Summer time is a much better time for visiting the Midwest states