C# windows system data exchange to Java system running on ubuntu linux

What do they mean by 'integrate'? Use the same database? Run locally as part of the same system? Be able to share data?

Do you have the ability to modify the Java system, or specify things that need to be in the interface? Creating either a web service/RPC endpoint or a TCP protocol for exchanging messages and data is much easier if you have the ability to add hooks to the other end. At the opposite end of that scale, if you have no control whatsoever, you sometimes have to resort to hackery like reading log files and faking keyboard/mouse input. But it sounds like you are working with the other developers to make integration work from both sides, which is good.

As long as you haven't used any SQL server specific features in the database code, moving to a different back end database should be trivial (just use different DataAdapter classes). If you have (I think some stored procedure stuff would come under this) then you would have to translate it before you could use a different database, and that can be tricky if PostGre doesn't have comparable extensions.

It is possible to run a C#/.Net application on Linux using Mono, as long as you haven't use P/Invoke (if you have you will need to find Linux native equivalents and switch between them depending on the build).

EDIT FOR UPDATE

Okay, so you don't want 'integration' as such but 'cooperation', i.e. the two systems able to interact with each other. Generally this is straight forward – expose a web service (if it's not time critical which it can't be if you are doing it manually now) at one end and call it with the other, actively to post new orders and polling to request updates on delivery progress.

The only problem here is the possible communication issues with a bad network. If you're concerned about duplicate requests, because a service call completed but the response was lost, you need to assign a request a UID on the client side before initially placing it, and include that ID in the initial request that's sent to the warehouse. If the Java system receives a duplicate ID it should reject it (with a sensible return code/exception, naturally). Similarly, delivery notes should either have an ID or be tied to the ID of the order they refer to, and after a client (by which I mean the web service client, i.e. the head office system) polls for new updates and the web service sends information about what is new, the client should send an acknowledgement including the IDs that it successfully retrieved an update for. That means that if the network goes down head office will see the same 'updated' delivery notes twice, but that's better than no times.

Another way to do the update synchronisation is to give each update a sequential ID and the client can make requests based on what the last update ID it saw was. This puts the responsibility in the client code (i.e. your head office code) and means one less service call; however it means that the server has to maintain all the updates because it doesn't know until a request comes in which ones it will need to send.

Depending on how it's done now this might require a couple of new tables or fields in the database at one or both ends, to keep track of what each side thinks it has sent to the other and what is awaiting collection as a new update.