You might consider letting the calendar handle some of the load. Subscriptions usually have a expiration date. Once that date is set you can then define what each recipient gets, every month until the expiration month arrives. That will make it much easier for your system to react when the recipient, for example, decides to take advantage of the "early renewal" bonus issue, etc. As opposed to having to unwind a pre-populated table. Consider it as a monthly batch process.
Thanks for the reply. I initially considered this however the solution then would require two shipping tables. One to handle subscriptions that depend on calendar triggered events and the other by single once off purchases. It got messy with generating a shipping report on an order with a mix of subscription and once off purchases. Thats why I decided to make it simple for the end user of the database and combine them into a simple to read straighforward list of shipments current and future. I dont know if this makes sense or I may be over complicating the process...