勝手ながら、
受注情報編集画面での「お届け先を削除」について検討してみました。

現状の更新処理（DBへの登録：関数doRegister）：
(1)　dtb_shipping

　　この処理は、注文番号内のお届け先をすべて、delete,insertにより更新している。
　　そのため、更新前と更新後のお届け先数が異なっても対応できる。（つまり、「お届け先を追加」「お届け先を削除」どちらも可能である）
(2)　dtb_shipment_item

　　この処理は、注文番号のお届け先番号内の商品をすべて、delete,insertにより更新している。
　　そのため、更新前と更新後の商品数が異なっても対応できる。（つまり、「商品の追加」「商品の削除」どちらも可能である）
　　しかし、$shipping_idが必須であるため、「お届け先を削除」した場合、削除した$shipping_idが不明になり対応できない。
　　（現状では、DB内に削除したお届け先の商品が残った状態となる。）

結論：
　　「お届け先の削除」は、実現可能であるが、前述のdtb_shipment_itemの残骸を削除する部分を作成する必要がある。
　　つまり、更新前（DB）と更新後（画面）を比較し、削除されたお届け先を削除したのち、既存の更新処理を行う形になる。

不具合：
　　テンプレートでは、
　　　　FORM_COUNTRY_ENABLE:trueの場合
shipping_country_id
shipping_zipcode
　　　　FORM_COUNTRY_ENABLE:falseの場合
shipping_country_id
　　の項目を展開する。
　　ここで、FORM_COUNTRY_ENABLE:falseの場合、
shipping_zipcode
　　がテンプレートにない。
　　また、classファイルでは、

　　を宣言し、FORM_COUNTRY_ENABLEに関係なくカラム名としてshipping_zipcodeを使っている。
　　つまり、テンプレートにない項目shipping_zipcodeを、classファイルで扱っており、
　　関数getValue, setValueで利用すると不具合が発生する。

追記（不具合の詳細）：
２口のお届け先の受注情報を１口のお届け先に更新する場合を例にする。

受注情報編集画面の画面表示にあたり、
(1) DBから受注情報を取得
(2) 各項目を画面遷移前の（項目の編集を行った）情報で上書き
(3) 画面を（画面遷移前の情報を引き継いで）表示
という手順になる。
ここで、FORM_COUNTRY_ENABLE:falseの場合、'shipping_zipcode'の項目が画面に存在していないので、(2)の段階で上書きの対象から除外される。
つまり、内部では、
　　'shipping_zipcode'は、２口
　　それ以外は、１口
という中途半端な状態になっている。
ここで、これらの内容からお届け先情報一覧を取り出すと、「'shipping_zipcode'は、２口」の影響で、
　　「内容が空の２口めが存在してしまう。」
という不具合です。

再追記：
LC_Page_Admin_Order_Edit.php

この定義で、'shipping_zipcode'は、お届け先情報の１つとして扱われているため、
画面上に定義されるべき項目だと思います。