Why is this bug affected to "Akretion team" ? Is there a good reason ? Well, if Akretion is granted with commit right on the addons, then I would love to keep the bug affected to Akretion :-)
About the bug itself : I don't agree with "a fiscal position with taxes should never be removed". What's the problem with removing a fiscal position with taxes ? I would prefer to have : "a fiscal position that it used on a partner/sale order/purchase order/invoice should be removable". In OpenERP 5.0 and 6.1 (I didn't test on other versions), you can remove a fiscal position that is used on an invoice ; I was quite suprised to see that. -- You received this bug notification because you are a member of OpenERP Indian Team, which is subscribed to OpenERP Addons. https://bugs.launchpad.net/bugs/873092 Title: account_fiscal_position should have a foreing rules to cancel removal Status in OpenERP Addons (modules): Confirmed Bug description: Dear all, This is OpenERP 6.03 with French accounting rules. While working on a new fiscal rule, I was able to delete an important rule, which is for applying taxes in the European Union. I had nearly a heart attack! Fortunately, I had a PostgreSQL backup and could access the table structure using pgAdmin3. This is table account_fiscal_position. I used vim to import the missing line. Then I discovered that the taxes registered in the fiscal rule had been removed also. At PostgreSQL level, there should be a foreign rule to cancel removing a fiscal rule when it contains taxes. The table definition is: CREATE TABLE account_fiscal_position_account ( id serial NOT NULL, create_uid integer, create_date timestamp without time zone, write_date timestamp without time zone, write_uid integer, position_id integer NOT NULL, -- Fiscal Position account_dest_id integer NOT NULL, -- Account Destination account_src_id integer NOT NULL, -- Account Source CONSTRAINT account_fiscal_position_account_pkey PRIMARY KEY (id ), CONSTRAINT account_fiscal_position_account_account_dest_id_fkey FOREIGN KEY (account_dest_id) REFERENCES account_account (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE SET NULL, CONSTRAINT account_fiscal_position_account_account_src_id_fkey FOREIGN KEY (account_src_id) REFERENCES account_account (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE SET NULL, CONSTRAINT account_fiscal_position_account_create_uid_fkey FOREIGN KEY (create_uid) REFERENCES res_users (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE SET NULL, CONSTRAINT account_fiscal_position_account_position_id_fkey FOREIGN KEY (position_id) REFERENCES account_fiscal_position (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE, CONSTRAINT account_fiscal_position_account_write_uid_fkey FOREIGN KEY (write_uid) REFERENCES res_users (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE SET NULL ) WITH ( OIDS=FALSE ); I don't know OpenERP very well, but I guess it there should be an additional check to cancel any accidental removal. A fiscal rule with taxes ... should never be removed. A user should remove taxes one by one and then remove the fiscal rule. This way, there is little chance for accidental removal. Also, just for information, I had used this rule in 100s of entries. So maybe removing a fiscal rule being used ... should not be allowed in any cases, as it breaks the information system. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-addons/+bug/873092/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~openerp-india Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-india More help : https://help.launchpad.net/ListHelp
