Notes forms are not like Word documents! You don't have page breaks and repeated headers like a Word document. Think of a form as a visual representation of a table row in a data file. To derive a solution to your PO scenario think first in terms of data, then think about the presentation. You should follow this approach anyway for all your developments. Basically on the PO you'll have some data that defines the PO in general terms e.g. PO number, vendor, date, address details etc. Then you've got the item related stuff which is repeated. In a relational database this would equate to probably 2 tables. One for the PO header and another for the PO item detail linked on PO number. You need to apply the same principles to your Notes form and basically arrive at the realisation that you need 2 forms pretty much exactly as per the relational db example. The key to simulating the relational db model in Notes is to make the PO item form a "response" to the PO header form. Set this in the form properties of the PO item form and have a button on the PO header form which creates a new PO item document. To present the data nicely, have a view listing all PO item documents and set the the first column value to @Text($Ref) and make it a sorted, categorised column. Then in the PO header form create an embedded view and set the parameter "Show single category" to @Text(@DocumentUniqueID). This effectively subsets the PO item view by the document id of the PO header document. Response documents store the document id of their parent document in field $Ref. This is a fairly standard technique for handling simple "1 to many" document relationships and a fits the PO problem fairly nicely.

Notes forms are not like Word documents! You don't have page breaks and repeated headers like a Word document. Think of a form as a visual representation of a table row in a data file. To derive a solution to your PO scenario think first in terms of data, then think about the presentation. You should follow this approach anyway for all your developments. Basically on the PO you'll have some data that defines the PO in general terms e.g. PO number, vendor, date, address details etc. Then you've got the item related stuff which is repeated. In a relational database this would equate to probably 2 tables. One for the PO header and another for the PO item detail linked on PO number. You need to apply the same principles to your Notes form and basically arrive at the realisation that you need 2 forms pretty much exactly as per the relational db example. The key to simulating the relational db model in Notes is to make the PO item form a "response" to the PO header form. Set this in the form properties of the PO item form and have a button on the PO header form which creates a new PO item document. To present the data nicely, have a view listing all PO item documents and set the the first column value to @Text($Ref) and make it a sorted, categorised column. Then in the PO header form create an embedded view and set the parameter "Show single category" to @Text(@DocumentUniqueID). This effectively subsets the PO item view by the document id of the PO header document. Response documents store the document id of their parent document in field $Ref. This is a fairly standard technique for handling simple "1 to many" document relationships and a fits the PO problem fairly nicely.