Community mailing list archives
Re: Accounting v9: updated specificationsby
Hi EricDoes your module handle "shipments", i.e. a shipment is probably one or more containers and the landed costs are applied to the shipment. Purchase orders are added to the shipment and the landed costs are disbursed across all these PO's when receipted. Additionally, it should be possible to receipt the shipment in one go.We have been meaning to do this but if we could contribute to your project to extend its functionality we will.ThanksOn 5 December 2014 at 11:58, Ana Juaristi <email@example.com> wrote:
Ups.. Sorry Eric, I didn't understand that you had the modules developed by now. I thougth you were telling the requirements. Problems of half reading messages.
Maybe we should think about taking the best of both aproaches and building a single one. Just a suggestion.
:)El 05/12/2014 01:38, "Caudal Eric" <firstname.lastname@example.org> escribió:EricHi Ana,Best
I ll have a look for v8. Our developments are done for v7 and probably will cover the same functional area.2014-12-05 8:22 GMT+08:00 Ana Juaristi <email@example.com>:Hi Eric:Maybe you would like to take a look to this module:https://github.com/odoomrp/odoomrp-wip/tree/8.0/purchase_landed_cost included on our OdooMRP projectIt's fully functional module that could be first aproach to have all the functionality you are asking for.It allows defining different kind of LC, even imported from invoces lines and distribute amount over picking lines products. It's modifying product cost on product form and in very short time will also modify quant cost and cost history table.It's not still finished but it covers our customer needed functionality by the moment.Let us know:Ana- Possibility to add LC rules between locations (eg transfer from duty free to duty paid with the corresponding taxes)- possibility to have separate duty zone (DZ) and cost price in a company. Meaning that you could have a LC on an internal move that will recalculate your DZ cost price and transfer from one balance sheet account to another.I think I never got answer on that topic which is really important.We will come up in the coming weeks with a set of modules for v7, summary of our past months analysis and deployment on the topic with:- Multicurrency LC- possibility to have container's assigned LC template to spread over several PO (container => PO => IS or later stock picking)- possibility to have LC on PO and SP for the following distribution keys: amount, unit, volume and weight- wizard to post the LC into average price and accounting that were not taken into account at PO or SP processing (Month end process)This topic and above features are very hot amongst my customers (I dont have any who doesnot request it and it is a legal requirements in some countries) and I am still wondering whether it will be taken into account properly in v9.Hi Fabien,Eric Caudal
Thanks for the feedback.
I am currently working on the accounting localization for a company in Singapore (in v7) and one of the main topics is the treatment of the landing costs in the accounting operations.
One of the requirements is that we need to be able to have a different cost for 2 main warehouses (inbond and duty-paid) with a one-way transaction (internal stock move) from Inbond to duty-paid with the corresponding fees (landing cost) associated.
As soon the goods arrive in DP location, the cost must be updated and include the cost of inbond + LC. When the sales invoice is validated (with AS accounting), COGS should be the cost associated to the location that originate the stock move (cost or cost+LC)
This kind of transaction is quite common in the countries we are currently dealing with (China, HK, SG, etc...) and quite standard for any company involved in international business trade (This is probably even true for large companies with several warehouses and high inter-warehouse transfer costs).
Currently Singaporian auditors cannot certify Odoo without this capability (multiple cost + LC proper management) and I wouldnot be surprised this would be the case for other countries.
Are there any plan to elaborate on this kind of requirement within this scope?
Should it be included as part of WMS management (currently in v8 there is a LC module and easier cost management at location level)?
In general, I see few requirements/proposal for changes on transaction setup (sales/purchase/stock) and for example the possibility in multi-company environment to select between continental / Anglosaxon accounting.
What are the plan on this particular topic?
Looking forward to reading you--Dear Odoo community, Following our accounting workshop with community members (around 25 attendees from UK, NL, BE, CH, FR, RO, DE), we updated the accounting specifications for version 9: https://docs.google.com/document/d/1MahXh0TdfjI0ohdTSz_c8cML7HqxvcAtvSAY63N20Tc/edit?usp=sharing We still have a few open questions for the community: 1/ does anyone use "Python" computed taxes for another reason than: rounding (at 0.05 in Switzerland) or division computation (like in Bolivia or Brazil) 2/ does anyone have refund Tax accounts that are different from the tax account of the related invoice? (I mean account.account, not account.tax.code) 3/ do you sometimes have for THE SAME invoice, some lines which are with tax included in price and other lines with tax excluded of the price? 4/ did you ever needed a tax with two levels? (a tax that has children and those children also have children) Please have a look at this document and check if it matches with your country requirements. Thanks, -- Fabien Pinckaers Odoo Founder Phone: +22.214.171.124.00 Web: https://www.odoo.com Twitter: @fpodoo Instant Demo: https://odoo.com/startEric CAUDAL+86 186 21 36 16 70
--Eric CAUDAL+86 186 21 36 16 70--CEO Avanzosc, S.L : Office phone / Tfono oficina: (+34) 943 02 69 02
Ana Juaristi Olalde : Personal phone: 677 93 42 59. User/usuario skype: Avanzosc
El contenido de esta comunicación y de toda su documentación anexa es confidencial y se dirige exclusivamente a su destinatario. El uso no autorizado de esta información está prohibido por la legislación vigente. Si usted no es el destinatario le rogamos nos lo indique, no comunique su contenido a terceros y proceda a su destrucción. Disculpe las molestias que le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse para ejercer sus derechos de acceso, rectificación, cancelación y oposición en Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 - firstname.lastname@example.org
Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu egiten du bertan eskainitako informazioa baimenik gabe erabiltzea. Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez, guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu. Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 - email@example.comThis message and all documents attached to it are confidential and intended only for the person or entity to which it is addressed. Any use of this information by unauthorised persons is prohibited under current legislation. If you received this message by error, please advise us, destroy it and refrain from communicating its contents to third parties. We apologise for any inconvenience receiving this email improperly may cause to you. Your personal data are included in a file owned by Avanzosc, S.L. If you want to exercise your rights of access, correction, erasure and objection you can contact the Controller at Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), T: 943 02 69 02 – firstname.lastname@example.org
--Eric CAUDAL+86 186 21 36 16 70