https://wiki.idempiere.org/w-en/api.php?action=feedcontributions&feedformat=atom&user=Tioraul 2026-05-05T08:11:57Z User contributions MediaWiki 1.35.2 https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=17613 2020-11-18T23:23:24Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Github Repository:''' [https://github.com/tioraulv/RUT/raw/master/VerificadorRutChile.zip]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://github.com/tioraulv/RUT/tree/master]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There are two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]<br /> [[Category:Localisation|C]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=17612 2020-11-18T23:19:22Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Github Repository:''' [https://github.com/tioraulv/RUT/raw/master/VerificadorRutChile.zip]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://github.com/tioraulv/RUT/blob/master/]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There are two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]<br /> [[Category:Localisation|C]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=17611 2020-11-18T23:14:21Z

<p>Tioraul: actualizando repositorios</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Github Repository:''' [https://github.com/tioraulv/RUT/blob/master/VerificadorRutChile.zip]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://github.com/tioraulv/RUT/blob/master/]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There are two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]<br /> [[Category:Localisation|C]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Fixed_Assets,_a_practical_example&diff=14534 2019-03-08T22:13:38Z

<p>Tioraul: </p> <hr /> <div><br /> <br /> &lt;big&gt;[https://youtu.be/Nyt36LBhPIA Please watch this video (spanish)]&lt;/big&gt;<br /> <br /> === Fixed Assets Setup ===<br /> <br /> <br /> ===== 1. Setup Depreciation Method. =====<br /> Only “Straight Line” is currently developed. Make sure to use “SL” as value in column<br /> DepreciationType.<br /> <br /> ===== 2. Setup Asset Group. =====<br /> Asset Group is where the default setup for asset is derived. <br /> Entry the Asset Group name and tick Owned and Depreciate. <br /> Note that there is a Default flag. When you tick it, this Asset Group Accounting information will become Default for all other new Asset Group.<br /> <br /> ===== 3. Setup Asset Group Acct =====<br /> This is where you set all parameters related to Depreciation calculation and all those Accounting<br /> account configurations. <br /> <br /> ===== 4. Setup Product Category =====<br /> Asset Group must be paired with Product Category. Create a product category for each asset group and set the Asset Group value.<br /> <br /> ===== 5. Setup Product =====<br /> <br /> • Product Category: you must set the appropriate Product Category that has been paired with a certain Asset Group.<br /> <br /> • Product Type: you must not use “Item”. Either “Expense” or Resource is recommended.<br /> <br /> • Product price list setup: include the product in a price list.<br /> <br /> <br /> <br /> ==== Asset Addition ====<br /> <br /> Asset Addition may be from:<br /> <br /> * Match Invoice (it will be explain below)<br /> * Import Asset<br /> * Project<br /> * Manual way<br /> <br /> <br /> == &lt;big&gt;Asset Addition from Match Invoice&lt;/big&gt; ==<br /> <br /> # Create and Complete a Purchase Order with product that will be a new asset.<br /> # Create and Complete a Material Receipt document and its lines using “create lines from”<br /> # Create an Invoice Vendor and use “Create Lines From” to automatically create Match Invoice. <br /> # In the Invoice Vendor line You should notice that the “Asset Related?” [now called 'Create Asset'] flag is ticked. <br /> # Select “Capital” value on field “Capital vs Expense” and you'll see the related Asset Group value on field “Asset Group”.<br /> # Complete the Vendor Invoice.<br /> # Enter to Asset addition window, search and complete the new Asset. (When Match Invoice document is completed, a new asset record and a new asset addition record will be automatically generated.)<br /> <br /> <br /> &lt;big&gt;[https://youtu.be/Nyt36LBhPIA Please watch this video (spanish)]&lt;/big&gt;<br /> <br /> The invoice vendor line will only show the link to the asset once the asset addition has been completed.<br /> <br /> <br /> <br /> [[NF1.0_Fixed_Assets]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=NF1.0_Fixed_Assets&diff=14533 2019-03-08T22:12:01Z

<p>Tioraul: link to Fixed Assets, a practical example</p> <hr /> <div>= '''Feature:''' Fixed Assets Stabilization =<br /> <br /> '''Goal:''' Functional<br /> <br /> '''Contributor:''' [[User:Edwinang|Edwin Ang]]<br /> <br /> '''Description:'''<br /> <br /> With the release 1.0 of iDempiere the Fixed Assets extension was fully integrated and a stabilization effort was contributed.<br /> <br /> [[User:Edwinang|Edwin Ang]] contributed a manual available at [http://bitbucket.org/edwinang/fixed_assets/downloads/iDempiere%20FA%20User%20Manual.pdf iDempiere FA User Manual.pdf]<br /> <br /> [http://www.ntier.co.za nTier Software services] contributed additional notes, see this [https://groups.google.com/forum/#!topic/idempiere/oPDbr0Sm4MY Google Groups Post], available [https://bitbucket.org/ntiersoftware/various/downloads/iDempiere%20FA%20User%20Manual%20Addendum.pdf here].<br /> <br /> '''Technical Info:''' [http://idempiere.atlassian.net/browse/IDEMPIERE-197 IDEMPIERE-197]<br /> <br /> [[Fixed Assets, a practical example]]<br /> <br /> <br /> [[Category:New Features|F]]<br /> [[Category:New Features v1.0|F]]<br /> [[Category:New Features Functional]]<br /> [[Category:User Manual‏‎]]<br /> [[Category:Financial accounting‏‎]]<br /> [[Category:Depreciation/amortization‏‎‏‏‎]]<br /> [[Category:Materials management‏‎]]<br /> [[Category:Materials management base data‏‎]]<br /> [[Category:Article base data‎]]<br /> [[Category:Price List‏‎]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Fixed_Assets,_a_practical_example&diff=14532 2019-03-08T22:10:16Z

<p>Tioraul: Created page with &quot; &lt;big&gt;[https://youtu.be/Nyt36LBhPIA Please watch this video (spanish)]&lt;/big&gt; === Fixed Assets Setup === ===== 1. Setup Depreciation Method. ===== Only “Straight Line”...&quot;</p> <hr /> <div><br /> <br /> &lt;big&gt;[https://youtu.be/Nyt36LBhPIA Please watch this video (spanish)]&lt;/big&gt;<br /> <br /> === Fixed Assets Setup ===<br /> <br /> <br /> ===== 1. Setup Depreciation Method. =====<br /> Only “Straight Line” is currently developed. Make sure to use “SL” as value in column<br /> DepreciationType.<br /> <br /> ===== 2. Setup Asset Group. =====<br /> Asset Group is where the default setup for asset is derived. <br /> Entry the Asset Group name and tick Owned and Depreciate. <br /> Note that there is a Default flag. When you tick it, this Asset Group Accounting information will become Default for all other new Asset Group.<br /> <br /> ===== 3. Setup Asset Group Acct =====<br /> This is where you set all parameters related to Depreciation calculation and all those Accounting<br /> account configurations. <br /> <br /> ===== 4. Setup Product Category =====<br /> Asset Group must be paired with Product Category. Create a product category for each asset group and set the Asset Group value.<br /> <br /> ===== 5. Setup Product =====<br /> <br /> • Product Category: you must set the appropriate Product Category that has been paired with a certain Asset Group.<br /> <br /> • Product Type: you must not use “Item”. Either “Expense” or Resource is recommended.<br /> <br /> • Product price list setup: include the product in a price list.<br /> <br /> <br /> <br /> ==== Asset Addition ====<br /> <br /> Asset Addition may be from:<br /> <br /> * Match Invoice (it will be explain below)<br /> * Import Asset<br /> * Project<br /> * Manual way<br /> <br /> <br /> == &lt;big&gt;Asset Addition from Match Invoice&lt;/big&gt; ==<br /> <br /> # Create and Complete a Purchase Order with product that will be a new asset.<br /> # Create and Complete a Material Receipt document and its lines using “create lines from”<br /> # Create an Invoice Vendor and use “Create Lines From” to automatically create Match Invoice. <br /> # In the Invoice Vendor line You should notice that the “Asset Related?” [now called 'Create Asset'] flag is ticked. <br /> # Select “Capital” value on field “Capital vs Expense” and you'll see the related Asset Group value on field “Asset Group”.<br /> # Complete the Vendor Invoice.<br /> # Enter to Asset addition window, search and complete the new Asset. (When Match Invoice document is completed, a new asset record and a new asset addition record will be automatically generated.)<br /> <br /> <br /> &lt;big&gt;[https://youtu.be/Nyt36LBhPIA Please watch this video (spanish)]&lt;/big&gt;<br /> <br /> The invoice vendor line will only show the link to the asset once the asset addition has been completed.</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Geografia_Chile:_LCL_Geografia&diff=14531 2019-03-03T21:29:25Z

<p>Tioraul: </p> <hr /> <div>== INSTALAR GEOGRAFIA DE CHILE ==<br /> <br /> * Descargue el paquete PaisChile.zip https://sourceforge.net/projects/adempierechile/files/PaisChile.zip/download<br /> <br /> * Ingrese en Idempiere con usuario SuperUser y Cliente System, en el Menu seleccione Pack In:<br /> * Dele un nombre al nuevo Pack In.<br /> * Adjunte (presione el icono de clip) el arichivo zip recien bajado.<br /> Luego Ok (el icono de ticket verde)<br /> Presione el botón PackIn<br /> Se demora algunos segundos y ya está la base de datos poblada con toda la geografía de Chile.<br /> <br /> * En el Menu seleccione Country Region and City<br /> * Busque Chile<br /> Active casillero Country Has Region<br /> Adecuar la secuencia de captura (Capture Sequence) para que considere Region: <br /> @CO@, @R@, @C@ @A1@ @A2@ @P@<br /> <br /> [https://youtu.be/_PQBpt_KINg Video Instalación Geografía Chile]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Localizations&diff=14530 2019-03-03T21:22:32Z

<p>Tioraul: </p> <hr /> <div>== Colombia ==<br /> <br /> [[Image:Qss.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CarlosRuiz|Carlos Ruiz]] - [http://globalqss.com Quality Systems &amp; Solutions GlobalQSS]<br /> * '''Last Update:''' January 9, 2019<br /> * '''Status:''' Up to date with release 6.2<br /> * '''Download URL:''' Look at installation guide<br /> * [http://wiki.idempiere.org/es/LCO_Instrucciones_Instalacion Installation Guide in Spanish]<br /> ** Plugins<br /> *** [[Plugin:_LCO_Detailed_Names|Nombres Detallados]]<br /> *** Medios Magnéticos<br /> *** Retenciones<br /> *** Control de Resoluciones para Numeración de Facturación<br /> ** Datos<br /> *** Geografía Capitales<br /> *** Geografía Completa<br /> *** Festivos<br /> *** Datos Ejemplo Retenciones para GardenWorld<br /> *** Datos Ejemplo Medios Magnéticos para GardenWorld<br /> ** [[Translations#Colombia|Lenguage es_CO]]<br /> <br /> == Chile ==<br /> <br /> * [[Geografia Chile: LCL Geografia|Geografia Chile (Regiones y Comunas) : LCL Geografia]]<br /> * [[Plugin: LCL Rut Taxid|Plugin: LCL Rut Taxid (Verificador RUT o CI Chileno)]]<br /> <br /> <br /> == Perú ==<br /> [[Image:Logo_egs_group-1-1.png‎|right|225px]]<br /> * '''Maintainer:''' [[User:PabloValdivia|Pablo Valdivia]] - [http://egs.pe EGS GROUP]<br /> * '''Last Update:''' July 20, 2014<br /> * '''Status:''' Up to date with release 2.0 <br /> * '''Source Code:''' [https://bitbucket.org/grupoegs/grupoegs-idempiere-lpe/wiki/Home Home bitbucket LPE]<br /> * '''Download URL:''' [https://bitbucket.org/grupoegs/grupoegs-idempiere-lpe/downloads downloads]<br /> ** Plugins<br /> *** [[:es:LPE_Instrucciones_Instalacion|LPE Asientos de Amarre]]<br /> ** LPE Archivos base<br /> *** [https://drive.google.com/file/d/0B49a4FHc8nJSTUVaY2hjMWt4bzQ/edit?usp=sharing Geografia de Perú]<br /> *** [https://drive.google.com/file/d/0B49a4FHc8nJSQ0lFYWp5aDRZSGM/edit?usp=sharing Plan Contable Empresarial Perú]<br /> <br /> == Brasil ==<br /> <br /> * '''Maintainer:''' [[User:Alan.lesc1|Alan Lescano]]<br /> * '''Status:''' on the road to 1.0<br /> * '''Source-code URL:''' [https://bitbucket.org/idempierelbr/idempierelbr https://bitbucket.org/idempierelbr/idempierelbr]<br /> ** Plugin<br /> *** [[Plugin:_LBR_Localization_Brazil|LBR Localization Brazil]]<br /> <br /> == España ==<br /> * '''Maintainer:''' [[User:Efekto2k|Efekto 2k]] -- - [http://www.tecnoxp.com TecnoXperience]<br /> * '''Last Update:''' November 14, 2014<br /> ** ''' Translation: ''' on November 18, 70%<br /> *** '''Status:''' Preparing to Up to date with release 2.0 <br /> *** '''Source Code:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location (Not finished yet)<br /> *** '''Download URL:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location (Not finished yet)<br /> ** ''' Account Schema ''' <br /> *** '''Status:''' Prepared to Up to date with release 2.0 <br /> *** '''Source Code:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location/src/40150d344aeff94650d04c9626307acc4e1da844/PLAN%20CONTABLE%20ESPA%C3%91A.csv?at=default<br /> *** '''Download URL:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location/src/40150d344aeff94650d04c9626307acc4e1da844/PLAN%20CONTABLE%20ESPA%C3%91A.csv?at=default<br /> ** ''' Spanish Regions ''' Already on trunk<br /> ** ''' Standar Account Reports ''' on November 18, 30%<br /> *** ''' Pérdidas y Ganancias '''<br /> *** ''' Balance de Situación '''<br /> *** ''' IVA '''<br /> *** ''' Diario del Mayor '''<br /> <br /> == Việt Nam ==<br /> * '''Maintainer:''' [[User:hieplq|Hiêp Lê Quý]]<br /> * '''Download URL:''' [https://bitbucket.org/hieplq/vn.hsv.vietnam.localization Bitbucket]<br /> ** Tiếng việt vi_vn<br /> *** '''Status:''' not yet complete, very bad translate ([https://translations.launchpad.net/idempiere-vi-vn online maintain])<br /> *** '''Data:''' folder /language<br /> *** '''Guideline:''' /language/step make translate to launchpad.txt<br /> ** ''' Account Schema ''' maintain file from age of adempiere<br /> *** '''Data:''' /accounting/AccountingVN-COA-QD15-VN.csv<br /> ** ''' Việt Name city list ''' List Việt Nam city with name, post code, phone code<br /> *** '''Data:''' use import csv to import file /city/VietNam_C_City.csv or run sql in /city/[database name]<br /> <br /> <br /> == Japan ==<br /> [[Image:JPiere-tate.png |200px|right|JPiere]]<br /> * '''Creator:''' [[User:Hideaki_Hagiwara|Hagiwara Hideaki]] in JAPAN (I'm sorry for my poor English. Please modify correctly if my English expressions are mistaken.)<br /> * '''SPONSOR:''' [http://www.oss-erp.co.jp/ OSS ERP Solutions] in JAPAN<br /> * '''Source:''' [https://bitbucket.org/jpiere/ Bitbucket JPiere repository] <br /> * '''More info(Japanese):'''[[:Plugin: Localization Japan|Plugin Localization Japan]]<br /> * '''More info(Japanese):'''[http://www.compiere-distribution-lab.net/jpiere-lab/ JPiere Lab] <br /> <br /> == Nicaragua ==<br /> <br /> [[Image:SAC.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CésarBaldelomar|César Baldelomar]] , [[User:obenavidez|Osmar Benavidez]] - [http://processus-erp.blogspot.com/ Soluciones Ágiles y Confiables]<br /> * '''Last Update:''' Octubre 05, 2016<br /> * '''Status:''' Up to date with release 3.1<br /> * '''Download URL:''' [https://bitbucket.org/CesarBaldelomar/lco_nicaragua/downloads]<br /> ** Plugins<br /> *** Retenciones<br /> *** Detalles<br /> *** LCO_Retenciones<br /> *** [[Plugin:Notifications |Notificaciones]]<br /> ** Datos<br /> *** Geografía Departamento - Municipios<br /> *** Elemento Contable<br /> ** Lenguage es_NI<br /> <br /> <br /> [[Category:User Manual]]<br /> [[Category:Setup]]<br /> [[Category:System administration]]<br /> [[Category:Localisation]]<br /> [[Category:Translation]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Localizations&diff=14529 2019-03-03T21:14:00Z

<p>Tioraul: </p> <hr /> <div>== Colombia ==<br /> <br /> [[Image:Qss.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CarlosRuiz|Carlos Ruiz]] - [http://globalqss.com Quality Systems &amp; Solutions GlobalQSS]<br /> * '''Last Update:''' January 9, 2019<br /> * '''Status:''' Up to date with release 6.2<br /> * '''Download URL:''' Look at installation guide<br /> * [http://wiki.idempiere.org/es/LCO_Instrucciones_Instalacion Installation Guide in Spanish]<br /> ** Plugins<br /> *** [[Plugin:_LCO_Detailed_Names|Nombres Detallados]]<br /> *** Medios Magnéticos<br /> *** Retenciones<br /> *** Control de Resoluciones para Numeración de Facturación<br /> ** Datos<br /> *** Geografía Capitales<br /> *** Geografía Completa<br /> *** Festivos<br /> *** Datos Ejemplo Retenciones para GardenWorld<br /> *** Datos Ejemplo Medios Magnéticos para GardenWorld<br /> ** [[Translations#Colombia|Lenguage es_CO]]<br /> <br /> == Chile ==<br /> <br /> * [https://sourceforge.net/projects/adempierechile/files/GeografiaChileIdempiere.zip/download Geografía Completa con Comunas y Regiones]<br /> * [[Geografia_Chile:_LCL_Geografia]]<br /> * [http://wiki.idempiere.org/en/Plugin:_LCL_Rut_Taxid Plugin Verificador RUT o CI chileno]<br /> <br /> <br /> == Perú ==<br /> [[Image:Logo_egs_group-1-1.png‎|right|225px]]<br /> * '''Maintainer:''' [[User:PabloValdivia|Pablo Valdivia]] - [http://egs.pe EGS GROUP]<br /> * '''Last Update:''' July 20, 2014<br /> * '''Status:''' Up to date with release 2.0 <br /> * '''Source Code:''' [https://bitbucket.org/grupoegs/grupoegs-idempiere-lpe/wiki/Home Home bitbucket LPE]<br /> * '''Download URL:''' [https://bitbucket.org/grupoegs/grupoegs-idempiere-lpe/downloads downloads]<br /> ** Plugins<br /> *** [[:es:LPE_Instrucciones_Instalacion|LPE Asientos de Amarre]]<br /> ** LPE Archivos base<br /> *** [https://drive.google.com/file/d/0B49a4FHc8nJSTUVaY2hjMWt4bzQ/edit?usp=sharing Geografia de Perú]<br /> *** [https://drive.google.com/file/d/0B49a4FHc8nJSQ0lFYWp5aDRZSGM/edit?usp=sharing Plan Contable Empresarial Perú]<br /> <br /> == Brasil ==<br /> <br /> * '''Maintainer:''' [[User:Alan.lesc1|Alan Lescano]]<br /> * '''Status:''' on the road to 1.0<br /> * '''Source-code URL:''' [https://bitbucket.org/idempierelbr/idempierelbr https://bitbucket.org/idempierelbr/idempierelbr]<br /> ** Plugin<br /> *** [[Plugin:_LBR_Localization_Brazil|LBR Localization Brazil]]<br /> <br /> == España ==<br /> * '''Maintainer:''' [[User:Efekto2k|Efekto 2k]] -- - [http://www.tecnoxp.com TecnoXperience]<br /> * '''Last Update:''' November 14, 2014<br /> ** ''' Translation: ''' on November 18, 70%<br /> *** '''Status:''' Preparing to Up to date with release 2.0 <br /> *** '''Source Code:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location (Not finished yet)<br /> *** '''Download URL:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location (Not finished yet)<br /> ** ''' Account Schema ''' <br /> *** '''Status:''' Prepared to Up to date with release 2.0 <br /> *** '''Source Code:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location/src/40150d344aeff94650d04c9626307acc4e1da844/PLAN%20CONTABLE%20ESPA%C3%91A.csv?at=default<br /> *** '''Download URL:''' https://bitbucket.org/tecnoxperience/idempiere_spanish_location/src/40150d344aeff94650d04c9626307acc4e1da844/PLAN%20CONTABLE%20ESPA%C3%91A.csv?at=default<br /> ** ''' Spanish Regions ''' Already on trunk<br /> ** ''' Standar Account Reports ''' on November 18, 30%<br /> *** ''' Pérdidas y Ganancias '''<br /> *** ''' Balance de Situación '''<br /> *** ''' IVA '''<br /> *** ''' Diario del Mayor '''<br /> <br /> == Việt Nam ==<br /> * '''Maintainer:''' [[User:hieplq|Hiêp Lê Quý]]<br /> * '''Download URL:''' [https://bitbucket.org/hieplq/vn.hsv.vietnam.localization Bitbucket]<br /> ** Tiếng việt vi_vn<br /> *** '''Status:''' not yet complete, very bad translate ([https://translations.launchpad.net/idempiere-vi-vn online maintain])<br /> *** '''Data:''' folder /language<br /> *** '''Guideline:''' /language/step make translate to launchpad.txt<br /> ** ''' Account Schema ''' maintain file from age of adempiere<br /> *** '''Data:''' /accounting/AccountingVN-COA-QD15-VN.csv<br /> ** ''' Việt Name city list ''' List Việt Nam city with name, post code, phone code<br /> *** '''Data:''' use import csv to import file /city/VietNam_C_City.csv or run sql in /city/[database name]<br /> <br /> <br /> == Japan ==<br /> [[Image:JPiere-tate.png |200px|right|JPiere]]<br /> * '''Creator:''' [[User:Hideaki_Hagiwara|Hagiwara Hideaki]] in JAPAN (I'm sorry for my poor English. Please modify correctly if my English expressions are mistaken.)<br /> * '''SPONSOR:''' [http://www.oss-erp.co.jp/ OSS ERP Solutions] in JAPAN<br /> * '''Source:''' [https://bitbucket.org/jpiere/ Bitbucket JPiere repository] <br /> * '''More info(Japanese):'''[[:Plugin: Localization Japan|Plugin Localization Japan]]<br /> * '''More info(Japanese):'''[http://www.compiere-distribution-lab.net/jpiere-lab/ JPiere Lab] <br /> <br /> == Nicaragua ==<br /> <br /> [[Image:SAC.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CésarBaldelomar|César Baldelomar]] , [[User:obenavidez|Osmar Benavidez]] - [http://processus-erp.blogspot.com/ Soluciones Ágiles y Confiables]<br /> * '''Last Update:''' Octubre 05, 2016<br /> * '''Status:''' Up to date with release 3.1<br /> * '''Download URL:''' [https://bitbucket.org/CesarBaldelomar/lco_nicaragua/downloads]<br /> ** Plugins<br /> *** Retenciones<br /> *** Detalles<br /> *** LCO_Retenciones<br /> *** [[Plugin:Notifications |Notificaciones]]<br /> ** Datos<br /> *** Geografía Departamento - Municipios<br /> *** Elemento Contable<br /> ** Lenguage es_NI<br /> <br /> <br /> [[Category:User Manual]]<br /> [[Category:Setup]]<br /> [[Category:System administration]]<br /> [[Category:Localisation]]<br /> [[Category:Translation]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Geografia_Chile:_LCL_Geografia&diff=14528 2019-03-03T21:01:40Z

<p>Tioraul: Instalacion Packin Geografia Chile</p> <hr /> <div>== INSTALAR GEOGRAFIA DE CHILE ==<br /> <br /> Descargue el paquete PaisChile.zip https://sourceforge.net/projects/adempierechile/files/PaisChile.zip/download<br /> <br /> Ingrese en Idempiere con usuario SuperUser y Cliente System, en el Menu seleccione Pack In:<br /> Dele un nombre al nuevo Pack In.<br /> Adjunte (presione el icono de clip) el arichivo zip recien bajado.<br /> Luego Ok (el icono de ticket verde)<br /> Presione el boton PackIn<br /> <br /> Se demora algunos segundos y ya está la base de datos poblada con toda la geografía de Chile.<br /> <br /> En el Menu seleccione Country Region and City<br /> Busque Chile<br /> Active casillero Country Has Region<br /> <br /> Adecuar la secuencia de captura (Capture Sequence) para que considere Region: <br /> @CO@, @R@, @C@ @A1@ @A2@ @P@<br /> <br /> [https://youtu.be/_PQBpt_KINg Video Instalación Geografía Chile]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14314 2018-07-28T18:23:41Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 character)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; standard logic e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; reference &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / release ===<br /> <br /> Workflows also allow to make the processing of a document dependent on a previous release. Thus, e.g. Invoices over 1.000, - € are always submitted to the superior or the like.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> Basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> Further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = Further information =<br /> <br /> == involved classes and interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table<br /> <br /> = Examples of implementing some DocAction methods =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Returns a short but unique name of the record, which is mainly used in log lines and other program messages. This example uses an existing document type.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> There is a method to output the document as a PDF. This will - as far as I've seen - only used to send the document by email. But because you never know, you can do that, e.g. as follows. Of course you can also choose more precisely when selecting the print format.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14313 2018-07-28T18:21:48Z

<p>Tioraul: </p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 character)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; standard logic e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; reference &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> Basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> Further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = Further information =<br /> <br /> == involved classes and interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table<br /> <br /> = Examples of implementing some DocAction methods =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Returns a short but unique name of the record, which is mainly used in log lines and other program messages. This example uses an existing document type.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> There is a method to output the document as a PDF. This will - as far as I've seen - only used to send the document by email. But because you never know, you can do that, e.g. as follows. Of course you can also choose more precisely when selecting the print format.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14312 2018-07-27T23:00:34Z

<p>Tioraul: </p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> Basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> Further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = Further information =<br /> <br /> == involved classes and interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table<br /> <br /> = Examples of implementing some DocAction methods =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Returns a short but unique name of the record, which is mainly used in log lines and other program messages. This example uses an existing document type.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> There is a method to output the document as a PDF. This will - as far as I've seen - only used to send the document by email. But because you never know, you can do that, e.g. as follows. Of course you can also choose more precisely when selecting the print format.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14311 2018-07-27T22:58:11Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = Further information =<br /> <br /> == involved classes and interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table<br /> <br /> = Examples of implementing some DocAction methods =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Returns a short but unique name of the record, which is mainly used in log lines and other program messages. This example uses an existing document type.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> There is a method to output the document as a PDF. This will - as far as I've seen - only used to send the document by email. But because you never know, you can do that, e.g. as follows. Of course you can also choose more precisely when selecting the print format.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14310 2018-07-27T22:50:41Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = Further information =<br /> <br /> == involved classes and interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table<br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14309 2018-07-27T22:49:08Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Articles that explain documents ==<br /> <br /> basic statements<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - quite new article by Daniel Tamm in the iDempiere Wiki, still has many gaps<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> further explanations<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Explanation of the action button and the window that opens up<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Extensions<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Improvement of document numbering (this allows context variables)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Improvement of organizations and restart of number ranges<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Extension, evidently never realized<br /> <br /> Articles that I use as sources, but have already incorporated much here:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - quite well explains the use of existing document types; less the development of new ones<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - contains short but insightful parts on the topic, in particular &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - Briefed forum thread about how to implement a workflow<br /> <br /> Windows related to documents:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (What is the difference between &quot;unprocessed&quot; and &quot;unposted&quot; and how do these windows know which tables to scan?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - what does this process do? He probably creates open entries for new document types. Is there anything else?<br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14308 2018-07-27T22:41:25Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Print ==<br /> <br /> Basically, you can print a record by clicking on the button in the toolbar for a report. This will then create a print format that you can adjust accordingly. If you often want to have individual data sets, for example As a form print as a list of sentences, so it is useful to activate the print button, with which you can print individual records. This is done by making an entry in the Process &amp; Report window. This was set to &quot;Report&quot; and indicates, if necessary, a prepared print format. This can then be started with the buttons for &quot;Print&quot; and &quot;Print preview&quot; by entering it in the window register record.<br /> <br /> By the way, there is a little problem here. You have to set up the &quot;Process &amp; Report&quot; window in the system client, whereas most of the time you have prepared your print format in the normal client. You can release the print format in this case. It is automatically selected the one that has set the field &quot;Standard&quot;.<br /> <br /> === Use Report View to print more columns than shown in the table ===<br /> <br /> An extension can be added by entering a similar entry in the field &quot;Report view&quot; in &quot;Process &amp; Report&quot;. In this case, a print format is selected that has selected this report view. This allows you to narrow the selection of the print format even further.<br /> <br /> In particular, one can also specify a report view based on a completely different table. This table should only contain the primary key field of our document because it will filter out the printed record. I used this, for example, to use a database view instead of the table edited in the current window for the expression, which, while based on that same table, adds a lot of additional data via JOIN. This large amount of information can then be restricted (if you like) through a report view and then processed in print format. Such a print format is created in the window &quot;Print format&quot;, where you can set the table and the view when creating the record. Then you create the fields by means of the automatic process button for this purpose and can then set the print format already in the target window and use it there in the print view. If this is the first time to see, then you can customize it as usual resulting print formats.<br /> <br /> === Print by program ===<br /> <br /> In my model for the BAY_InterestCalculation table, I can use the following method to get an expression based on a view called RV_BAY_InterestCalculation. One can use this method e.g. in completeIt () to make sure that a document is always printed when it completes. Incidentally, one can set in the process window whether the printout happens immediately in the background or only with consultation.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Artikel, die Dokumente erklären ==<br /> <br /> Basiserklärungen<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - recht neuer Artikel von Daniel Tamm im iDempiere Wiki, hat noch viele Lücken<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> weiterführende Erklärungen<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Erklärung zum Action Button und dem davon aufgehenden Fenster<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Erweiterungen<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Verbesserung der Dokumentnummerierung (hierdurch sind Kontextvariablen erlaubt)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Verbesserung bzgl. Organisationen und Neustart von Nummernkreisen<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Erweiterung, augenscheinlich nie verwirklicht worden<br /> <br /> Artikel, die ich als Quellen verwendet, aber bereits weitgehend hier eingearbeitet habe:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - erklärt recht gut die Benutzung der vorhandenen Dokumenttypen; weniger die Entwicklung neuer<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - enthält kurze, aber aufschlussreiche Teile zum Thema, insbesondere &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - kurzed Forumsthread darüber, wie man einen Workflow implementieren kann<br /> <br /> Fenster, die mit Dokumenten zusammenhängen:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (Was ist der Unterschied zwischen &quot;unprocessed&quot; und &quot;unposted&quot; und woher wissen diese Fenster, welche Tabellen sie absuchen sollen?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - was macht dieser Prozeß? Er erzeugt wohl Open-Einträge für neue Dokumenttypen. Sonst noch was?<br /> <br /> <br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14307 2018-07-27T22:35:51Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Windows, tabs &amp; fields ==<br /> <br /> The window should be set to the window type &quot;Transaction&quot;. This turns on [[http://www.adempiere.com/History History]]. This ensures that only the current and incomplete documents are displayed.<br /> <br /> Incidentally, when configuring the window, the following fields should be displayed (according to Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (if used, it may be read-only)<br /> <br /> For documents that differentiate purchasing and sales documents, it makes sense to copy them and introduce a WHERE clause, so that you have two windows for these actually different document types. You can define a window as a sales transaction in the window definition, and thus set a context variable that is used in many queries and validations to ensure that all fields work properly. Of course, this requires some care in generating your own queries, but there are enough existing examples, such &quot;Invoice (Customer)&quot; and &quot;Invoice (Supplier)&quot;.<br /> <br /> == Drucken ==<br /> <br /> Grnudsätzlich kann man einen Datensatz ausdrucken, indem man in der Toolbar auf den Button für einen entsprechenden Bericht klickt. Durch diesen wird dann ein Druckformat erzeugt, das man entsprechend anpassen kann. Will man oft eher einzelne Datensätze z.B. als Formular drucken als eine Liste von Sätzen, so bietet es sich an, den Druck-Button zu aktivieren, mit dem man einzelne Datensätze drucken kann. Das macht man, indem man im Fenster &quot;Prozeß &amp; Bericht&quot; einen Eintrag macht. Diesen setzte man auf &quot;Bericht&quot; und gibt ggf. ein vorbereitetes Druckformat an. Dieses kann dann mit mit den Buttons für &quot;Druck&quot; und &quot;Druckvorschau&quot; gestartet werden, indem man es im Datensatz des Fensterregisters einträgt.<br /> <br /> Hier gibt es übrigens ein kleines Problem. Das Fenster &quot;Prozeß &amp; Bericht&quot; muss man im Systemmandanten einrichten, während man sein Druckformat ja zumeist vorher im normalen Mandanten vorbereitet hat. Man kann in diesem Fall das Druckformat freilassen. Es wird automatisch das gewählt, das das Feld &quot;Standard&quot; gesetzt hat.<br /> <br /> === Berichtsansicht benutzen, um mehr Spalten auszudrucken als in der Tabelle stehen ===<br /> <br /> Eine Erweiterung gibt es noch, indem man in &quot;Prozeß &amp; Bericht&quot; im Feld &quot;Berichtsansicht&quot; eine ebensolche einträgt. In diesem Fall wird ein Druckformat ausgewählt, das ebendiese Berichtsansicht ausgewählt hat. Hierdurch kann man die Auswahl des Druckformats noch weiter eingrenzen.<br /> <br /> Insbesondere kann man hier auch eine Berichtsansicht angeben, die auf einer ganz anderen Tabelle basiert. Diese Tabelle sollte lediglich das Primärschlüsselfeld unseres Dokumentes beinhalten, weil hierdurch der ausgedruckte Datensatz heruasgefiltert wird. Ich habe das beispielsweise benutzt, um anstatt der im aktuellen Fenster bearbeiteten Tabelle ein Datenbank-View für den Ausdruck zu benutzen, das zwar auf ebendieser Tabelle basiert, ihnr per JOIN aber jede Menge weitere Daten hinzufügt. Diese grosse Menge an Informationen kann man dann (wenn man möchte) durch eine Berichtsansicht wieder einschränken und dann im Druckformat verarbeiten. Ein derartiges Druckformat erzeugt man im Fenster &quot;Druckformat&quot;, wo man die Tabelle und die Ansicht bei der Neuanlage des Datensatzes einstellen kann. Dann erzeugt man die Felder mittels des automatischen Proßess-Knopfes hierfür und kann dann das Druckformat schon im Zielfenster einstellen und dort in der Druckansicht benutzen. Ist diese das erste Mal zu sehen, kann man es dann wie gewöhnlich entstandene Druckformate auch anpassen.<br /> <br /> === Drucken per Programm ===<br /> <br /> Mit der folgenden Methode kann ich in meinem Model für die Tabelle BAY_InterestCalculation einen Ausdruck veranlassen, der auf einem View basiert, das RV_BAY_InterestCalculation heisst. Man kann diese Methode z.B. in completeIt() aufrufen, um dafür zu sorgen, das ein Dokument immer gedruckt wird, wenn es abgeschlossen wird. Man kann übrigens im Prozeßfenster einstellen, ob der Ausdruck sofort im Hintergrund oder erst mit Rückfrage geschieht.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Artikel, die Dokumente erklären ==<br /> <br /> Basiserklärungen<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - recht neuer Artikel von Daniel Tamm im iDempiere Wiki, hat noch viele Lücken<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> weiterführende Erklärungen<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Erklärung zum Action Button und dem davon aufgehenden Fenster<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Erweiterungen<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Verbesserung der Dokumentnummerierung (hierdurch sind Kontextvariablen erlaubt)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Verbesserung bzgl. Organisationen und Neustart von Nummernkreisen<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Erweiterung, augenscheinlich nie verwirklicht worden<br /> <br /> Artikel, die ich als Quellen verwendet, aber bereits weitgehend hier eingearbeitet habe:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - erklärt recht gut die Benutzung der vorhandenen Dokumenttypen; weniger die Entwicklung neuer<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - enthält kurze, aber aufschlussreiche Teile zum Thema, insbesondere &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - kurzed Forumsthread darüber, wie man einen Workflow implementieren kann<br /> <br /> Fenster, die mit Dokumenten zusammenhängen:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (Was ist der Unterschied zwischen &quot;unprocessed&quot; und &quot;unposted&quot; und woher wissen diese Fenster, welche Tabellen sie absuchen sollen?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - was macht dieser Prozeß? Er erzeugt wohl Open-Einträge für neue Dokumenttypen. Sonst noch was?<br /> <br /> <br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14306 2018-07-27T22:33:23Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Purchase and sales documents ==<br /> <br /> If you have a document category that is supposed to post different purchasing and sales documents (AP and AR), you also need this field. With this type of document, it is generally appropriate to also generate two separate basic document types and possibly two separate windows. The window definitions can be largely identical except for the &quot;Sales Transaction&quot; entry, which sets the context variable &quot;IsSOTrx&quot; and thus makes it distinguishable.<br /> <br /> * isSOTrx (mandatory; boolean, in the window best not displayed nciht or at least write-protected)<br /> <br /> == Fenster, Tab &amp; Felder ==<br /> <br /> Das Fenster sollte auf den Fenstertyp &quot;Transaktion&quot; gesetzt werden. Dadurch wird die [[http://www.adempiere.com/History History-Funktion]] aktiviert. Diese sorgt dafür, das immer nur die aktuellen und nicht abgeschlossenen Dokumente angezeigt werden.<br /> <br /> Bei der Konfiguration des Fensters sollten übrigens die folgenden Felder angezeigt werden (laut Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (wenn benutzt sollte es u.U. schreibgeschützt sein)<br /> <br /> Für Dokumente, die Einkaufs- und Verkaufsbelege unterscheiden, bietet es sich an, diese zu kopieren und eine WHERE-Klasel einzuführen, so das man zwei Fenster für diese eigentlich unterschiedlichen Belegtypen hat. Man kann in der Fensterdefinition ein Fenster als Verkaufstransaktion definieren und somit eine Kontextvariable setzen, die in vielen Abfragen und Validierungen benutzt wird, um sicherzustellen, das alle Felder entsprechend angepasst funktionieren. Das erfordert natürlich bei der Erzeugung eigener Abfragen etwas Sorgfalt, aber es gibt ja genug bestehende Beispiele wie z.B. &quot;Rechnung (Kunde)&quot; und &quot;Rechnung (Lieferant)&quot;.<br /> <br /> <br /> == Drucken ==<br /> <br /> Grnudsätzlich kann man einen Datensatz ausdrucken, indem man in der Toolbar auf den Button für einen entsprechenden Bericht klickt. Durch diesen wird dann ein Druckformat erzeugt, das man entsprechend anpassen kann. Will man oft eher einzelne Datensätze z.B. als Formular drucken als eine Liste von Sätzen, so bietet es sich an, den Druck-Button zu aktivieren, mit dem man einzelne Datensätze drucken kann. Das macht man, indem man im Fenster &quot;Prozeß &amp; Bericht&quot; einen Eintrag macht. Diesen setzte man auf &quot;Bericht&quot; und gibt ggf. ein vorbereitetes Druckformat an. Dieses kann dann mit mit den Buttons für &quot;Druck&quot; und &quot;Druckvorschau&quot; gestartet werden, indem man es im Datensatz des Fensterregisters einträgt.<br /> <br /> Hier gibt es übrigens ein kleines Problem. Das Fenster &quot;Prozeß &amp; Bericht&quot; muss man im Systemmandanten einrichten, während man sein Druckformat ja zumeist vorher im normalen Mandanten vorbereitet hat. Man kann in diesem Fall das Druckformat freilassen. Es wird automatisch das gewählt, das das Feld &quot;Standard&quot; gesetzt hat.<br /> <br /> === Berichtsansicht benutzen, um mehr Spalten auszudrucken als in der Tabelle stehen ===<br /> <br /> Eine Erweiterung gibt es noch, indem man in &quot;Prozeß &amp; Bericht&quot; im Feld &quot;Berichtsansicht&quot; eine ebensolche einträgt. In diesem Fall wird ein Druckformat ausgewählt, das ebendiese Berichtsansicht ausgewählt hat. Hierdurch kann man die Auswahl des Druckformats noch weiter eingrenzen.<br /> <br /> Insbesondere kann man hier auch eine Berichtsansicht angeben, die auf einer ganz anderen Tabelle basiert. Diese Tabelle sollte lediglich das Primärschlüsselfeld unseres Dokumentes beinhalten, weil hierdurch der ausgedruckte Datensatz heruasgefiltert wird. Ich habe das beispielsweise benutzt, um anstatt der im aktuellen Fenster bearbeiteten Tabelle ein Datenbank-View für den Ausdruck zu benutzen, das zwar auf ebendieser Tabelle basiert, ihnr per JOIN aber jede Menge weitere Daten hinzufügt. Diese grosse Menge an Informationen kann man dann (wenn man möchte) durch eine Berichtsansicht wieder einschränken und dann im Druckformat verarbeiten. Ein derartiges Druckformat erzeugt man im Fenster &quot;Druckformat&quot;, wo man die Tabelle und die Ansicht bei der Neuanlage des Datensatzes einstellen kann. Dann erzeugt man die Felder mittels des automatischen Proßess-Knopfes hierfür und kann dann das Druckformat schon im Zielfenster einstellen und dort in der Druckansicht benutzen. Ist diese das erste Mal zu sehen, kann man es dann wie gewöhnlich entstandene Druckformate auch anpassen.<br /> <br /> === Drucken per Programm ===<br /> <br /> Mit der folgenden Methode kann ich in meinem Model für die Tabelle BAY_InterestCalculation einen Ausdruck veranlassen, der auf einem View basiert, das RV_BAY_InterestCalculation heisst. Man kann diese Methode z.B. in completeIt() aufrufen, um dafür zu sorgen, das ein Dokument immer gedruckt wird, wenn es abgeschlossen wird. Man kann übrigens im Prozeßfenster einstellen, ob der Ausdruck sofort im Hintergrund oder erst mit Rückfrage geschieht.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Artikel, die Dokumente erklären ==<br /> <br /> Basiserklärungen<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - recht neuer Artikel von Daniel Tamm im iDempiere Wiki, hat noch viele Lücken<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> weiterführende Erklärungen<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Erklärung zum Action Button und dem davon aufgehenden Fenster<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Erweiterungen<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Verbesserung der Dokumentnummerierung (hierdurch sind Kontextvariablen erlaubt)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Verbesserung bzgl. Organisationen und Neustart von Nummernkreisen<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Erweiterung, augenscheinlich nie verwirklicht worden<br /> <br /> Artikel, die ich als Quellen verwendet, aber bereits weitgehend hier eingearbeitet habe:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - erklärt recht gut die Benutzung der vorhandenen Dokumenttypen; weniger die Entwicklung neuer<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - enthält kurze, aber aufschlussreiche Teile zum Thema, insbesondere &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - kurzed Forumsthread darüber, wie man einen Workflow implementieren kann<br /> <br /> Fenster, die mit Dokumenten zusammenhängen:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (Was ist der Unterschied zwischen &quot;unprocessed&quot; und &quot;unposted&quot; und woher wissen diese Fenster, welche Tabellen sie absuchen sollen?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - was macht dieser Prozeß? Er erzeugt wohl Open-Einträge für neue Dokumenttypen. Sonst noch was?<br /> <br /> <br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14305 2018-07-27T22:30:15Z

<p>Tioraul: google translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Document base type ==<br /> <br /> Our new document type must also have an entry in the database. However, we first have to think about which basic type he belongs to. This base type is used for sorting and grouping document types, in particular for the document type input fields. In addition, the period can be opened or closed in the period control (in the calendar) for each individual basic document category. Although, interestingly enough, it is not necessarily mandatory, it still makes sense to set up a document base type for your own accounting document class.<br /> <br /> The base document type consists of an entry in the reference list &quot;C_DocType DocBaseType&quot; and always has three letters. If you want, you can set up a type &quot;DOC&quot; for all your documents here. However, it makes more sense to create your own basic types for each document type you create. Then, a selection field in the window can be validated to filter for this basic type and the user will always be able to generate their own derivations later.<br /> <br /> For some base types of the standard iDempiere, multiple base types work with objects of the same table. For example, by splitting &quot;API Accounts Payable Invoice&quot; and &quot;ARI Accounts Receivable Invoice&quot; ensures that incoming and outgoing invoices are never mixed. Although both are in the same table and use much the same business logic, they each have their own windows and are also distinguished by the field &quot;isSOTrx&quot; (and the different base document type). Due to the two basic document types, a simple validation on the input field for the document type is enough, so that you can only select sales document types for customers and vice versa.<br /> <br /> After you have created the basic document categories (in the system client), you should now call the process &quot;Check Document Types&quot; in the client. This creates a document type for each base document type and also directly creates corresponding period entries in the calendar.<br /> <br /> The automatically generated document types can be viewed in the &quot;Document type&quot; window and adjusted if necessary. It is recommended to activate number management and specify (or create) a document number range.<br /> <br /> In this window you can now derive even more document types from its basic document category. This has different purposes:<br /> <br /> * First of all, this can serve the in-house grouping of documents. Anyone who thinks in his business that a bill of goods is different from a service bill and a foreign bill, in turn, differently and a freight bill, can divide this so without much trouble.<br /> * You can specify your own print format (in this window) and make the printed receipt look very different.<br /> * You can group direct bookings (batches) using the direct posting type (fee type depending on the translation) and only allow specific bookings for certain document types. Thus, the freight invoice can be posted to the account for freight, the foreign invoice to the account for customs, etc.<br /> <br /> Next, you should create a validation rule. This gets the name &quot;C_DocType MyPatementName&quot; and as SQL-Code something like the following line:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Of course, you can omit the part with IsSOTrx if we do not have a separate document type for input and output windows. This part of the formula ensures that we can use identical field definitions for incoming and outgoing documents. The two windows then differ only in that the context variable &quot;IsSOTrx&quot; is set when the window is opened. This will then control everything else. This value can be set in the window definition.<br /> <br /> == Einkaufs- und Verkaufsbelege ==<br /> <br /> Wer einen Belegtyp hat, der Einkaufs- und Verkaufsbelege (AP und AR) unterschiedlich verbuchen soll, braucht auch noch dieses Feld. Bei dieser Art Belegen bietet es sich im Allgemeinen an, auch zwei getrennte Basisbelegtypen und ggf. zwei getrennte Fenster zu erzeugen. Die Fensterdefinitionen können weitgehend identisch sein bis auf den Eintrag &quot;Verkaufstransaktion&quot;, der die Kontextvariable &quot;IsSOTrx&quot; setzt und sie somit unterscheidbar macht.<br /> <br /> * isSOTrx (mandatory; boolean; im Fenster am besten gar nciht angezeigt oder mindestens schreibgeschützt)<br /> <br /> <br /> == Fenster, Tab &amp; Felder ==<br /> <br /> Das Fenster sollte auf den Fenstertyp &quot;Transaktion&quot; gesetzt werden. Dadurch wird die [[http://www.adempiere.com/History History-Funktion]] aktiviert. Diese sorgt dafür, das immer nur die aktuellen und nicht abgeschlossenen Dokumente angezeigt werden.<br /> <br /> Bei der Konfiguration des Fensters sollten übrigens die folgenden Felder angezeigt werden (laut Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (wenn benutzt sollte es u.U. schreibgeschützt sein)<br /> <br /> Für Dokumente, die Einkaufs- und Verkaufsbelege unterscheiden, bietet es sich an, diese zu kopieren und eine WHERE-Klasel einzuführen, so das man zwei Fenster für diese eigentlich unterschiedlichen Belegtypen hat. Man kann in der Fensterdefinition ein Fenster als Verkaufstransaktion definieren und somit eine Kontextvariable setzen, die in vielen Abfragen und Validierungen benutzt wird, um sicherzustellen, das alle Felder entsprechend angepasst funktionieren. Das erfordert natürlich bei der Erzeugung eigener Abfragen etwas Sorgfalt, aber es gibt ja genug bestehende Beispiele wie z.B. &quot;Rechnung (Kunde)&quot; und &quot;Rechnung (Lieferant)&quot;.<br /> <br /> <br /> == Drucken ==<br /> <br /> Grnudsätzlich kann man einen Datensatz ausdrucken, indem man in der Toolbar auf den Button für einen entsprechenden Bericht klickt. Durch diesen wird dann ein Druckformat erzeugt, das man entsprechend anpassen kann. Will man oft eher einzelne Datensätze z.B. als Formular drucken als eine Liste von Sätzen, so bietet es sich an, den Druck-Button zu aktivieren, mit dem man einzelne Datensätze drucken kann. Das macht man, indem man im Fenster &quot;Prozeß &amp; Bericht&quot; einen Eintrag macht. Diesen setzte man auf &quot;Bericht&quot; und gibt ggf. ein vorbereitetes Druckformat an. Dieses kann dann mit mit den Buttons für &quot;Druck&quot; und &quot;Druckvorschau&quot; gestartet werden, indem man es im Datensatz des Fensterregisters einträgt.<br /> <br /> Hier gibt es übrigens ein kleines Problem. Das Fenster &quot;Prozeß &amp; Bericht&quot; muss man im Systemmandanten einrichten, während man sein Druckformat ja zumeist vorher im normalen Mandanten vorbereitet hat. Man kann in diesem Fall das Druckformat freilassen. Es wird automatisch das gewählt, das das Feld &quot;Standard&quot; gesetzt hat.<br /> <br /> === Berichtsansicht benutzen, um mehr Spalten auszudrucken als in der Tabelle stehen ===<br /> <br /> Eine Erweiterung gibt es noch, indem man in &quot;Prozeß &amp; Bericht&quot; im Feld &quot;Berichtsansicht&quot; eine ebensolche einträgt. In diesem Fall wird ein Druckformat ausgewählt, das ebendiese Berichtsansicht ausgewählt hat. Hierdurch kann man die Auswahl des Druckformats noch weiter eingrenzen.<br /> <br /> Insbesondere kann man hier auch eine Berichtsansicht angeben, die auf einer ganz anderen Tabelle basiert. Diese Tabelle sollte lediglich das Primärschlüsselfeld unseres Dokumentes beinhalten, weil hierdurch der ausgedruckte Datensatz heruasgefiltert wird. Ich habe das beispielsweise benutzt, um anstatt der im aktuellen Fenster bearbeiteten Tabelle ein Datenbank-View für den Ausdruck zu benutzen, das zwar auf ebendieser Tabelle basiert, ihnr per JOIN aber jede Menge weitere Daten hinzufügt. Diese grosse Menge an Informationen kann man dann (wenn man möchte) durch eine Berichtsansicht wieder einschränken und dann im Druckformat verarbeiten. Ein derartiges Druckformat erzeugt man im Fenster &quot;Druckformat&quot;, wo man die Tabelle und die Ansicht bei der Neuanlage des Datensatzes einstellen kann. Dann erzeugt man die Felder mittels des automatischen Proßess-Knopfes hierfür und kann dann das Druckformat schon im Zielfenster einstellen und dort in der Druckansicht benutzen. Ist diese das erste Mal zu sehen, kann man es dann wie gewöhnlich entstandene Druckformate auch anpassen.<br /> <br /> === Drucken per Programm ===<br /> <br /> Mit der folgenden Methode kann ich in meinem Model für die Tabelle BAY_InterestCalculation einen Ausdruck veranlassen, der auf einem View basiert, das RV_BAY_InterestCalculation heisst. Man kann diese Methode z.B. in completeIt() aufrufen, um dafür zu sorgen, das ein Dokument immer gedruckt wird, wenn es abgeschlossen wird. Man kann übrigens im Prozeßfenster einstellen, ob der Ausdruck sofort im Hintergrund oder erst mit Rückfrage geschieht.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Artikel, die Dokumente erklären ==<br /> <br /> Basiserklärungen<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - recht neuer Artikel von Daniel Tamm im iDempiere Wiki, hat noch viele Lücken<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> weiterführende Erklärungen<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Erklärung zum Action Button und dem davon aufgehenden Fenster<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Erweiterungen<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Verbesserung der Dokumentnummerierung (hierdurch sind Kontextvariablen erlaubt)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Verbesserung bzgl. Organisationen und Neustart von Nummernkreisen<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Erweiterung, augenscheinlich nie verwirklicht worden<br /> <br /> Artikel, die ich als Quellen verwendet, aber bereits weitgehend hier eingearbeitet habe:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - erklärt recht gut die Benutzung der vorhandenen Dokumenttypen; weniger die Entwicklung neuer<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - enthält kurze, aber aufschlussreiche Teile zum Thema, insbesondere &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - kurzed Forumsthread darüber, wie man einen Workflow implementieren kann<br /> <br /> Fenster, die mit Dokumenten zusammenhängen:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (Was ist der Unterschied zwischen &quot;unprocessed&quot; und &quot;unposted&quot; und woher wissen diese Fenster, welche Tabellen sie absuchen sollen?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - was macht dieser Prozeß? Er erzeugt wohl Open-Einträge für neue Dokumenttypen. Sonst noch was?<br /> <br /> <br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Hackers_Guide_to_Documents&diff=14304 2018-07-27T22:16:38Z

<p>Tioraul: Google Translate</p> <hr /> <div>= Modes of document characteristics =<br /> <br /> == Document number ==<br /> <br /> If a table has a column with the title DocumentNo, it will be treated automatically in a special way. In the first usage of the table a sequence will be installed, which takes care of a consecutively document numeration. This document number can be edited more precisly in [[Belegnummernkreis (Fenster_ID-112)]]. It can be set as a determinded initial value or it can preserve a prefix or a suffix. Document numbers can also have a context variable where a date can be fit, e.g.Rechnung 00001/2014&quot; (s.e.g. [[:en:NF001_Document_Sequence_Improved]]).<br /> <br /> == Model ==<br /> <br /> For a document type, which implements its own logic, you need to write a model. This means you create its own plugin, where you write a java class, the so-called model class (M*). This has to be derived from a predeterminded basis class (X_*). In turn this will be created with the help of the tool [[GenerateModel]] from the table definition of the data bank.<br /> <br /> === Columns ===<br /> <br /> For the best you setup these following columns:<br /> <br /> * DocumentNo (mandatory; 30 Zeichen)<br /> * DateDoc (mandatory)<br /> * DateAcct (mandatory)<br /> * Doc_User_ID (either a column or a getter-methode, which reads out a column like SalesRep_ID or standard logic, e.g. '@$C_Currency_ID@').<br /> * C_Currency_ID (mandatory; Standardlogik e.g. &quot;@$C_Currency_ID@')<br /> * DocAction (mandatory; 2 characters; default 'CO'; pushbutton; reference &quot;_Document Action&quot;; here will be a process indicated, which indicates the according workflow of our document type)<br /> * DocStatus (mandatory; 2 characters; default 'DR'; list reference; Referenz &quot;_Document Status&quot; )<br /> * processed (mandatory; default 'N')<br /> * processing (mandatory; default 'N') - after Dantam's article is a varchar(1), supposely the pushbutton. For example in C_Invoice is the same process inscribed like in DocAction. But until now I have no idea why you need two columns.<br /> * isApproved (mandatory; default 'Y')<br /> <br /> === What does DocumentEngine do in the process? ===<br /> <br /> Document actions will be done by the class DocEngine. Who wants to conduct a status operation, can do this best with the odel-method processIt(). This should invoke the accordingly method of DocEngine, which takes over the management of different status possibilties.<br /> <br /> * http://www.adempiere.com/Document_Engine - u.a. links to Sourcecode of Doc_* classes<br /> * http://www.adempiere.com/Development_Guidelines_in_German#Klasse_DocumentEngine - german introduction, written quite well<br /> <br /> == Workflow ==<br /> <br /> You can install a receipt-Workflow which defines the change between several status values. You define a Workflow with three nodes: Start, Prepare and Complete. The two last ones will be combined with the last receipt action, therewith these take action. Then you definde a transition which in each case from Start to Prepare and from Prepare to Complete.<br /> <br /> This defined Workflow provides for properly done documents. It serves for further experiments.<br /> <br /> === Reversing documents ===<br /> <br /> Who wants to reverse documents, requires these following columns in addition:<br /> <br /> * Reversal_ID (reference type table, as a reference you need to register new created table reference, which close about my whole table and can be assorted after DocumentNo)<br /> <br /> I never tried this reversal. Probably you need to configure an accordingly Workflow. Besides this you should be very careful, if you want to reverse booked documents.<br /> <br /> === Reactivating Documents ===<br /> <br /> I would like to reactivate my document, after it is finalizied. In addition I created a further node 'Reactivate' and attached this with the accordingly receipt action. Then I definded a second transition with the start to Reactivate. The first transition has a condition, which only takes action, if 'Doc-Action = 'CO''. Besides this the first transition obtains a small order of numbers, which executes first.<br /> <br /> As a matter of principle the reactivating requires a reversal of the effects of the document. This implementation is not needed, but I recommend you this.<br /> <br /> === Approval / Freigabe ===<br /> <br /> Workflows erlauben auch, die Bearbeitung eines Dokumentes von einer vorherigen Freigabe abhängig zu machen. So können z.B. Rechnungen über 1.000,- € immer erst dem Vorgesetzten vorgelegt werden oder dergleichen.<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> <br /> === More about Workflows ===<br /> <br /> taken from http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow:<br /> <br /> Every document has a defined process – the workflow is started with the Process button:&lt;br /&gt;<br /> These workflows have a defined start context (the document) and a responsible.<br /> * Start (Draft)<br /> ** Auto<br /> ** Prepare (In Progress)<br /> *** Complete (Completed)<br /> <br /> If you want to customize a workflow for a document:&lt;br /&gt;<br /> * for all clients<br /> ** add customized node/transitions and/or inactivate standard transitions<br /> * for a client or organization<br /> ** make changes on System workflow with entity type &lt;&gt; Dictionary/Adempiere<br /> ** execute process “Workflow to Client”<br /> <br /> == Booking Document ==<br /> <br /> A document that can generate its own posting lines must contain the following fields:<br /> <br /> * Posted (mandatory; boolean; default 'N')<br /> * ProcessedOn (integer)<br /> * C_DocType_ID (mandatory; Table; reference C_DocType)<br /> <br /> The corresponding logic is activated by the presence of the &quot;Posted&quot; field. In this case, after completing a document, an update class matching the model is used to carry out the update. For this there is the convention that this ends on &quot;_Doc&quot;. Within the iDempiere kernel, the name of this class (based on this convention) is automatically determined. In ADempiere this was also the case for own classes. In iDempiere, which no longer allows core access to our plugin classes through the OSGi packages, there is a factory for that purpose.<br /> <br /> == Dokument-Basisbelegtyp ==<br /> <br /> Unser neuer Belegtyp muss auch einen Eintrag in der Datenbank erhalten. Dazu müssen wir uns allerdings zuerst überlegen, welchem Basistyp er zugehört. Dieser Basistyp dient der Sortierung und Gruppierung von Belegtypen insbesondere für die Belegtyp-Eingabefelder. Außerdem kann/muss in der Periodenkontrolle (im Kalender) für jeden einzelnen Basisbelegtyp die Periode geöffnet oder geschlossen werden. Obwohl es interessanterweise nicht unbedingt zwingend vorgeschrieben ist, bietet es sich dennoch an, für eine eigene verbuchende Dokumentenklasse auch einen Dokument-Basistyp einzurichten. <br /> <br /> Der Basisbelegtyp besteht aus einem Eintrag in der Referenzliste &quot;C_DocType DocBaseType&quot; und hat immer drei Buchstaben. Wer möchte, kann hier prinzipiell für alle seine Dokumente einen Typ &quot;DOC&quot; einrichten. Allerdings ist es sinnvoller, für jeden Belegtyp, den man erzeugt, einen eigenen Basistypen zu erzeugen. Dann kann ein Auswahlfeld im Fenster per Validierung nach diesem Basistyp filtern und dem Benutzer bleibt so später immer die Möglichkeit, eigene Ableitungen zu generieren.<br /> <br /> Bei einigen Basistypen des Standard-iDempiere ist es so, das mehrere Basistypen mit Objekten derselben Tabelle arbeiten. So ist z.B. durch die Aufteilung &quot;API Accounts Payable Invoice&quot; und &quot;ARI Accounts Receivable Invoice&quot; sichergestellt, das Eingangs- und Ausgangsrechnungen niemals gemischt werden. Beide stehen zwar in derselben Tabelle und benutzen weitgehend dieselbe Geschäftslogik, sie haben jedoch jeweils eigene Fenster und werden auch durch das Feld &quot;isSOTrx&quot; (und eben den unterschiedlichen Basisbelegtyp) unterschieden. Durch die zwei Basis-Belegtypen reicht eine einfache Validierung auf dem Eingabefeld für den Belegtyp, so das man für Kunden auch wirklich nur Verkaufs-Belegtypen auswählen kann und umgekehrt.<br /> <br /> Nachdem man die Basis-Belegtypen erstellt hat (im System-Mandant), sollte man nun im Mandanten den Prozeß &quot;Belegarten überprüfen&quot; aufrufen. Dieser legt zu jeder Basisbelegart eine Belegart an und erzeugt auch direkt entsprechende Perioden-Einträge im Kalender.<br /> <br /> Die so automatisch erzeugten Belegarten kann man im Fenster &quot;Belegart&quot; ansehen und ggf. anpassen. Es empfiehlt sich, die Nummernverwaltung einzuschalten und einen Belegnummernkreis anzugeben (oder neu zu erzeugen).<br /> <br /> In diesem Fenster kann man nun noch weitere Belegarten von seinem Basisbelegtyp ableiten. Das hat verschiedene Zwecke:<br /> <br /> * Zuerst einmal kann das der betriebsinternen Gruppierung von Belegen dienen. Wer in seinem Betrieb meint, das eine Warenrechnung anders ist als eine Dienstleistungsrechnung und eine Auslandsrechnung wiederum anders und eine Frachtrechnung auch, kann das so ohne grosse Probleme aufteilen.<br /> * Man kann (in diesem Fenster) ein eigenes Druckformat angeben und so den gedruckten Beleg ganz anders aussehen lassen.<br /> * Man kann die Direktbuchungen (Charge) über die Direktbuchungsart (Gebührenart je nach Übersetzung) gruppieren und für bestimmte Belegarten nur bestimmte Buchungen erlauben. So kann also die Frachtrechnung auf das Konto für Fracht buchen, die Auslandsrechnung auf das Konto für Zoll, etc.<br /> <br /> Als nächstes sollte man eine Validierungsregel erstellen. Diese bekommt den Namen &quot;C_DocType MeinBelegtypname&quot; und als SQL-Code sowas wie die folgende Zeile:<br /> <br /> C_DocType.DocBaseType IN ('ARZ', 'APZ') AND C_DocType.IsSOTrx='@IsSOTrx@' AND C_DocType.AD_Client_ID=@#AD_Client_ID@<br /> <br /> Den Teil mit IsSOTrx kann man natürlich weglassen, wenn wir keinen getrennten Belegtyp für Eingangs- und Ausgangsfenster haben. Dieser Teil der Formel sorgt dafür, das wir identische Felddefinitionen für Eingangs- und Ausgangsbelege nehmen können. Die beiden Fenster unterscheiden sich dann nur dadurch, das beim Öffnen des Fensters die Kontextvariable &quot;IsSOTrx&quot; gesetzt wird. Hiermit wird dann alles andere gesteuert. Das dieser Wert gesetzt ist, kann man in der Fensterdefinition einstellen.<br /> <br /> <br /> == Einkaufs- und Verkaufsbelege ==<br /> <br /> Wer einen Belegtyp hat, der Einkaufs- und Verkaufsbelege (AP und AR) unterschiedlich verbuchen soll, braucht auch noch dieses Feld. Bei dieser Art Belegen bietet es sich im Allgemeinen an, auch zwei getrennte Basisbelegtypen und ggf. zwei getrennte Fenster zu erzeugen. Die Fensterdefinitionen können weitgehend identisch sein bis auf den Eintrag &quot;Verkaufstransaktion&quot;, der die Kontextvariable &quot;IsSOTrx&quot; setzt und sie somit unterscheidbar macht.<br /> <br /> * isSOTrx (mandatory; boolean; im Fenster am besten gar nciht angezeigt oder mindestens schreibgeschützt)<br /> <br /> <br /> == Fenster, Tab &amp; Felder ==<br /> <br /> Das Fenster sollte auf den Fenstertyp &quot;Transaktion&quot; gesetzt werden. Dadurch wird die [[http://www.adempiere.com/History History-Funktion]] aktiviert. Diese sorgt dafür, das immer nur die aktuellen und nicht abgeschlossenen Dokumente angezeigt werden.<br /> <br /> Bei der Konfiguration des Fensters sollten übrigens die folgenden Felder angezeigt werden (laut Dantam):<br /> <br /> * Processed (set to &quot;Read Only&quot;)<br /> * DocStatus (set to &quot;Read Only&quot;)<br /> * DocAction<br /> * Currency (wenn benutzt sollte es u.U. schreibgeschützt sein)<br /> <br /> Für Dokumente, die Einkaufs- und Verkaufsbelege unterscheiden, bietet es sich an, diese zu kopieren und eine WHERE-Klasel einzuführen, so das man zwei Fenster für diese eigentlich unterschiedlichen Belegtypen hat. Man kann in der Fensterdefinition ein Fenster als Verkaufstransaktion definieren und somit eine Kontextvariable setzen, die in vielen Abfragen und Validierungen benutzt wird, um sicherzustellen, das alle Felder entsprechend angepasst funktionieren. Das erfordert natürlich bei der Erzeugung eigener Abfragen etwas Sorgfalt, aber es gibt ja genug bestehende Beispiele wie z.B. &quot;Rechnung (Kunde)&quot; und &quot;Rechnung (Lieferant)&quot;.<br /> <br /> <br /> == Drucken ==<br /> <br /> Grnudsätzlich kann man einen Datensatz ausdrucken, indem man in der Toolbar auf den Button für einen entsprechenden Bericht klickt. Durch diesen wird dann ein Druckformat erzeugt, das man entsprechend anpassen kann. Will man oft eher einzelne Datensätze z.B. als Formular drucken als eine Liste von Sätzen, so bietet es sich an, den Druck-Button zu aktivieren, mit dem man einzelne Datensätze drucken kann. Das macht man, indem man im Fenster &quot;Prozeß &amp; Bericht&quot; einen Eintrag macht. Diesen setzte man auf &quot;Bericht&quot; und gibt ggf. ein vorbereitetes Druckformat an. Dieses kann dann mit mit den Buttons für &quot;Druck&quot; und &quot;Druckvorschau&quot; gestartet werden, indem man es im Datensatz des Fensterregisters einträgt.<br /> <br /> Hier gibt es übrigens ein kleines Problem. Das Fenster &quot;Prozeß &amp; Bericht&quot; muss man im Systemmandanten einrichten, während man sein Druckformat ja zumeist vorher im normalen Mandanten vorbereitet hat. Man kann in diesem Fall das Druckformat freilassen. Es wird automatisch das gewählt, das das Feld &quot;Standard&quot; gesetzt hat.<br /> <br /> === Berichtsansicht benutzen, um mehr Spalten auszudrucken als in der Tabelle stehen ===<br /> <br /> Eine Erweiterung gibt es noch, indem man in &quot;Prozeß &amp; Bericht&quot; im Feld &quot;Berichtsansicht&quot; eine ebensolche einträgt. In diesem Fall wird ein Druckformat ausgewählt, das ebendiese Berichtsansicht ausgewählt hat. Hierdurch kann man die Auswahl des Druckformats noch weiter eingrenzen.<br /> <br /> Insbesondere kann man hier auch eine Berichtsansicht angeben, die auf einer ganz anderen Tabelle basiert. Diese Tabelle sollte lediglich das Primärschlüsselfeld unseres Dokumentes beinhalten, weil hierdurch der ausgedruckte Datensatz heruasgefiltert wird. Ich habe das beispielsweise benutzt, um anstatt der im aktuellen Fenster bearbeiteten Tabelle ein Datenbank-View für den Ausdruck zu benutzen, das zwar auf ebendieser Tabelle basiert, ihnr per JOIN aber jede Menge weitere Daten hinzufügt. Diese grosse Menge an Informationen kann man dann (wenn man möchte) durch eine Berichtsansicht wieder einschränken und dann im Druckformat verarbeiten. Ein derartiges Druckformat erzeugt man im Fenster &quot;Druckformat&quot;, wo man die Tabelle und die Ansicht bei der Neuanlage des Datensatzes einstellen kann. Dann erzeugt man die Felder mittels des automatischen Proßess-Knopfes hierfür und kann dann das Druckformat schon im Zielfenster einstellen und dort in der Druckansicht benutzen. Ist diese das erste Mal zu sehen, kann man es dann wie gewöhnlich entstandene Druckformate auch anpassen.<br /> <br /> === Drucken per Programm ===<br /> <br /> Mit der folgenden Methode kann ich in meinem Model für die Tabelle BAY_InterestCalculation einen Ausdruck veranlassen, der auf einem View basiert, das RV_BAY_InterestCalculation heisst. Man kann diese Methode z.B. in completeIt() aufrufen, um dafür zu sorgen, das ein Dokument immer gedruckt wird, wenn es abgeschlossen wird. Man kann übrigens im Prozeßfenster einstellen, ob der Ausdruck sofort im Hintergrund oder erst mit Rückfrage geschieht.<br /> <br /> public void print() {<br /> int viewTable = MTable.getTable_ID(&quot;RV_&quot; + Table_Name);<br /> MPrintFormat format = new Query(getCtx(), MPrintFormat.Table_Name, MPrintFormat.COLUMNNAME_AD_Table_ID<br /> + &quot;=? AND &quot; + MPrintFormat.COLUMNNAME_IsDefault + &quot;=? &quot;, get_TrxName()).setParameters(viewTable, &quot;Y&quot;)<br /> .first();<br /> MQuery query = new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0], MQuery.EQUAL, get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentInfo(), get_Table_ID(), get_ID());<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> re.print();<br /> }<br /> <br /> = Links =<br /> <br /> == Artikel, die Dokumente erklären ==<br /> <br /> Basiserklärungen<br /> <br /> * http://wiki.idempiere.org/en/Create_a_custom_document_class - recht neuer Artikel von Daniel Tamm im iDempiere Wiki, hat noch viele Lücken<br /> * http://www.adempiere.com/How_to_create_a_new_document_with_specific_accounting<br /> <br /> weiterführende Erklärungen<br /> <br /> * http://www.adempiere.com/How_to_Activate_Document_Approval_Workflow<br /> * http://www.adempiere.com/Document_Action_Dialog - Erklärung zum Action Button und dem davon aufgehenden Fenster<br /> * http://www.adempiere.com/Document_Sequence - Document Sequence<br /> * Erweiterungen<br /> ** http://www.adempiere.com/Enhance_Document_No_Formatting - Verbesserung der Dokumentnummerierung (hierdurch sind Kontextvariablen erlaubt)<br /> ** http://wiki.idempiere.org/en/NF001_Document_Sequence_Improved - Verbesserung bzgl. Organisationen und Neustart von Nummernkreisen<br /> ** http://www.adempiere.com/Sponsored_Development:_Document_Signing - Document Signing Erweiterung, augenscheinlich nie verwirklicht worden<br /> <br /> Artikel, die ich als Quellen verwendet, aber bereits weitgehend hier eingearbeitet habe:<br /> <br /> * http://www.adempiere.com/HOWTO_Process_Documents - erklärt recht gut die Benutzung der vorhandenen Dokumenttypen; weniger die Entwicklung neuer<br /> * http://en.wikiversity.org/wiki/Adempiere_Technical_Training#Document_Process_Workflow - enthält kurze, aber aufschlussreiche Teile zum Thema, insbesondere &quot;Document Process Workflow&quot;<br /> * http://www.adempiere.com/Document_Engine<br /> * https://groups.google.com/forum/#!topic/idempiere/WtTlVL1ZjWw - kurzed Forumsthread darüber, wie man einen Workflow implementieren kann<br /> <br /> Fenster, die mit Dokumenten zusammenhängen:<br /> <br /> * http://wiki.idempiere.org/en/Document_Type_%28Window_ID-135%29<br /> * http://wiki.idempiere.org/en/Document_Sequence_%28Window_ID-112%29<br /> <br /> * http://wiki.idempiere.org/en/Unprocessed_Documents_%28All%29_%28Window_ID-53087%29<br /> * http://wiki.idempiere.org/en/UnPosted_Documents_%28Window_ID-294%29<br /> * http://wiki.idempiere.org/en/My_Unprocessed_Documents_%28Window_ID-53086%29<br /> * http://wiki.idempiere.org/de/Workflow_%28Fenster_ID-113%29<br /> <br /> (Was ist der Unterschied zwischen &quot;unprocessed&quot; und &quot;unposted&quot; und woher wissen diese Fenster, welche Tabellen sie absuchen sollen?)<br /> <br /> * http://wiki.idempiere.org/en/Verify_Document_Types_%28Process_ID-233%29 - was macht dieser Prozeß? Er erzeugt wohl Open-Einträge für neue Dokumenttypen. Sonst noch was?<br /> <br /> <br /> <br /> = weitere Informationen =<br /> <br /> == involvierte Klassen und Interfaces ==<br /> <br /> === MSetup ===<br /> <br /> Create the list of document type for new Client ( Method createAccounting ). <br /> <br /> === org.compiere.server.AcctProcessor ===<br /> <br /> Background process running on the JBoss server that perform the accounting document posting process. <br /> <br /> === org.compiere.grid.ed.VDocAction ===<br /> <br /> Define hardcoded in dynInit method the list of possible transitions, and transitions by table <br /> <br /> <br /> = Beispiele für die Implementierung einiger DocAction-Methoden =<br /> <br /> === getDocumentInfo() ===<br /> <br /> Ergibt eine kurze aber eindeutige Bezeichnung des Datensatzes, die vor allem in Logzeilen und sonstigen Programm-Mitteilungen verwendet wird. Dieses Beispiel nutzt einen vorhandenen Documenttyp.<br /> <br /> public String getDocumentInfo(){<br /> MDocType dt = MDocType.get(getCtx(), getC_DocType_ID());<br /> String msgreturn = dt.getNameTrl()+&quot; &quot;+getDocumentNo();<br /> return msgreturn.toString();<br /> }<br /> <br /> === createPDF() ===<br /> <br /> Es gibt eine Methode, um das Dokument als PDF auszugeben. Diese wird - soweit ich gesehen habe - nur benutzt, um das Dokument per EMail zu versenden. Da man aber nie weiss, kann man das z.B. so wie folgend implementieren. Dabei kann man bei der Auswähl des Printformats natürlich auch genauer auswählen.<br /> <br /> public File createPDF (){<br /> try{<br /> StringBuilder msgfile = new StringBuilder().append(get_TableName()).append(get_ID()).append(&quot;_&quot;);<br /> File temp = File.createTempFile(msgfile.toString(), &quot;.pdf&quot;);<br /> return createPDF (temp);<br /> }catch (Exception e){<br /> log.severe(&quot;Could not create PDF - &quot; + e.getMessage());<br /> }<br /> return null;<br /> }<br /> <br /> public File createPDF (File file){<br /> MPrintFormat format = MPrintFormat.get(getCtx(), 0, get_Table_ID());<br /> MQuery query=new MQuery(get_Table_ID());<br /> query.addRestriction(get_KeyColumns()[0],MQuery.EQUAL,get_ID());<br /> PrintInfo info = new PrintInfo(getDocumentNo(),get_Table_ID(),0);<br /> ReportEngine re = new ReportEngine(getCtx(), format, query, info, get_TrxName());<br /> <br /> if(format.getJasperProcess_ID() &gt; 0){<br /> // JasperReports Print Format<br /> ProcessInfo pi = new ProcessInfo (&quot;&quot;, format.getJasperProcess_ID());<br /> pi.setRecord_ID(get_ID());<br /> pi.setIsBatch(true);<br /> ServerProcessCtl.process(pi, null);<br /> return pi.getPDFReport();<br /> }else{<br /> // Standard Print Format (Non-Jasper)<br /> return re.getPDF(file);<br /> }<br /> }<br /> <br /> <br /> [[Category:Development‏‎]]<br /> [[Category:Developer documentation‏‎]]<br /> [[Category:System administration‏‎]]<br /> [[Category:Applying means‏‎]]<br /> [[Category:Document‎]]<br /> [[Category:Workflow]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Business_Partner_Manual&diff=14295 2018-06-01T15:16:11Z

<p>Tioraul: </p> <hr /> <div>__TOC__<br /> <br /> This tutorial is brought to you by Dr. Stanley Mungwe from IT-Kamer Company Ltd and ERP University Cameroon (http://erp-university-africa.com). If you have questions, criticism or improvement suggestions, feel free to visit me ([[User:Doctor|Doctor]]) or write me [mailto:sales@itkamer.com an email]. Thanks goes to Jan Thielmann for the initial discussions around this.<br /> <br /> =Goal of Manual=<br /> The goal of this manual is to give you an introduction to Business Partner in Idempiere from a user's perspective.<br /> <br /> <br /> =Introduction to Business Partner=<br /> A Business Partner in Idempiere represents an entity with whom you carry out business operations. Idempiere differentiates three different types of Business Partners: Vendors, Customers, and Employees or any combination of the three.<br /> <br /> A Business Partner should have one or more Locations and one or more Contacts, which can or may not be linked to a location. Contacts can have Interest Areas. These Interest Areas are the basis for Customer Relationship Management and gives a sales personnel or sales representative the opportunity to manage Email-Lists. <br /> <br /> In Idempiere a Business Partner also possess a &quot;Bank Account&quot; and &quot;Withholding&quot; capabilities.<br /> <br /> Relationships can exist between Business Partners and other Business Partners. This enables a Sales Order to be shipped to one Business Partner and Invoiced to a second Business Partner.<br /> <br /> <br /> <br /> [[Category:User Manual]]<br /> [[Category: Business Partner]]<br /> [[Category: Business Partner base data]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Install_Prerequisites&diff=14117 2017-12-11T22:50:09Z

<p>Tioraul: </p> <hr /> <div>&lt;!-- breadcrumb --&gt;<br /> &lt;font size=-2&gt;<br /> &amp;lArr;<br /> [[Installing iDempiere|Table of Contents]] |<br /> Install Prerequisites |<br /> [[Downloading Installers]]<br /> &amp;rArr;<br /> &lt;/font&gt;<br /> <br /> In order to run iDempiere you need to have a JDK (not JRE) version of java, and a proper database (PostgreSQL and Oracle are supported).<br /> <br /> The examples on this guide are using the following versions:<br /> * Ubuntu 16.04.1 64 bits<br /> * PostgreSQL 9.6.1<br /> * PostgreSQL contrib (for UUID support)<br /> * OpenJDK 1.8.0_91<br /> <br /> But this guide can be used in other systems (even Windows) taking care of installing the corresponding packages and using corresponding commands.<br /> <br /> == Install Ubuntu ==<br /> <br /> Please refer to http://www.ubuntu.com/download<br /> <br /> Downloaded and installed Ubuntu Server 16.04.1 LTS<br /> <br /> == Install PostgreSQL 9.6.1 ==<br /> <br /> iDempiere can also run with Oracle 10G or 11G, and also with PostgreSQL 8.4 to 9.3, but for this tutorial we use postgresql 9.4.1 - see http://www.postgresql.org/download/linux/ubuntu/ for details<br /> <br /> echo &quot;deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main&quot; | sudo tee /etc/apt/sources.list.d/pgdg.list<br /> wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -<br /> sudo apt-get update<br /> sudo apt-get install postgresql-9.6 postgresql-contrib-9.6<br /> sudo service postgresql start<br /> sudo update-rc.d postgresql defaults<br /> <br /> === Assign a password to user postgres ===<br /> <br /> In order to create the database the installer needs to know the password of user postgres, by default this user doesn't have a password in ubuntu (windows installer asks for a password).<br /> <br /> In the event that there's no 'postgres' role in your postgres db, you have to create on your own using the following steps:<br /> <br /> # Connect to your postgres db instance via psql.<br /> # Create 'postgres' role via &quot;CREATE USER postgres&quot; without the double quote.<br /> # Alter the role and specify what the role suppose to be. EX. &quot;ALTER USER postgres SUPERUSER CREATEDB&quot; without the double quote.<br /> <br /> Then you can proceed to the following steps.<br /> <br /> Please take note of the password you assign here as it will be required in the setup process:<br /> <br /> Steps are (replace your_chosen_password by your preferred):<br /> <br /> sudo su - postgres<br /> psql -U postgres -c &quot;alter user postgres unencrypted password 'your_chosen_password'&quot;<br /> logout<br /> <br /> == Install OpenJDK 1.8.0_91 ==<br /> <br /> sudo apt-get install openjdk-8-jdk<br /> <br /> Now you have your prerequisites ready to receive the iDempiere installer<br /> <br /> == Troubleshooting ==<br /> <br /> === Linux ===<br /> <br /> After installing postgres you must check the correct configuration of /etc/postgresql/9.6/main/pg_hba.conf.<br /> These two entries must be configured to use password (md5):<br /> local all all md5<br /> host all all 127.0.0.1/32 md5<br /> NOTE that some guides suggest configuring trust - but that creates a security issue on your postgres server.<br /> <br /> === Windows ===<br /> <br /> Most installation problems in Windows are caused by not configured environment variables:<br /> * PATH must be configured to make the commands psql and jar accessible<br /> * JAVA_HOME environment variable must be configured<br /> <br /> <br /> ''This tutorial is brought to you by [[User:CarlosRuiz|Carlos Ruiz]] from [http://globalqss.com GlobalQSS]. Feel free to improve directly or suggest using the Discussion tab.<br /> <br /> <br /> [[Category:User Manual|I]]<br /> [[Category:Installation|L]] <br /> [[Category:Installation Linux]] <br /> [[Category:Installation Windows]]<br /> [[Category:Installation Server‏‎]]<br /> [[Category:Installation Database‏‎]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=11908 2017-09-01T01:06:21Z

<p>Tioraul: corrige link archivo zip</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/downloads/VerificadorRutChile.zip]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There are two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]<br /> [[Category:Localisation|C]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Queries:_AD&diff=6968 2015-05-15T22:02:46Z

<p>Tioraul: /* Tabs */</p> <hr /> <div>[[Category:Code Scratchpad]]<br /> <br /> = Client =<br /> <br /> &lt;nowiki&gt;select ad_client_id,value,name from ad_client order by ad_client_id;&lt;/nowiki&gt;<br /> <br /> = Windows =<br /> == Tabs ==<br /> <br /> &lt;nowiki&gt;select b.name as WindowName from ad_tab a<br /> join ad_window b on a.ad_window_id = b.ad_window_id<br /> where <br /> a.ad_table_id = <br /> (select ad_table_id from ad_table where name='tablename');&lt;/nowiki&gt;<br /> <br /> == Combining Window, tab, field ==<br /> <br /> &lt;nowiki&gt;select <br /> win.name as WindowName, <br /> tab.name as TabName,<br /> tabtable.tablename as TabTable, <br /> fld.name as field_display_name, <br /> fld.displaylogic as field_display_logic,<br /> fld.readonlylogic as field_readonly_logic,<br /> col.columnname as column_name,<br /> ref.name as ref_name, refvalue.name as ref_value,<br /> refvalue.ad_reference_id,<br /> reftabletbl.tablename as ref_table<br /> from <br /> ad_field fld<br /> join ad_tab tab on fld.ad_tab_id = tab.ad_tab_id<br /> join ad_table tabtable on tabtable.ad_table_id = tab.ad_table_id<br /> join ad_window win on tab.ad_window_id = win.ad_window_id<br /> join ad_column col on fld.ad_column_id = col.ad_column_id<br /> left join ad_reference ref on col.ad_reference_id = ref.ad_reference_id<br /> left join ad_reference refvalue on col.ad_reference_value_id = refvalue.ad_reference_id<br /> left join ad_ref_table reftable on reftable.ad_reference_id = refvalue.ad_reference_id<br /> left join ad_table reftabletbl on reftabletbl.ad_table_id = reftable.ad_table_id<br /> where <br /> --upper(win.name) like upper('Window Name') and<br /> fld.isdisplayed = 'Y' -- and<br /> --upper(col.columnname) = upper('columnname')<br /> upper(fld.name) like upper('Field Name')<br /> --upper(tabtable.tablename) = upper('tablename')<br /> order by win.name, tab.seqno, col.columnname<br /> ;&lt;/nowiki&gt;<br /> <br /> == Shorter field info ==<br /> <br /> &lt;nowiki&gt;select <br /> --win.name as WindowName, <br /> tab.name as TabName,<br /> tabtable.tablename as TabTable, <br /> fld.seqno,<br /> fld.name as field_display_name, <br /> --fld.displaylogic as field_display_logic,<br /> --fld.readonlylogic as field_readonly_logic,<br /> col.columnname as column_name<br /> --ref.name as ref_name, refvalue.name as ref_value,<br /> --refvalue.ad_reference_id,<br /> --reftabletbl.tablename as ref_table<br /> from <br /> ad_field fld<br /> join ad_tab tab on fld.ad_tab_id = tab.ad_tab_id<br /> join ad_table tabtable on tabtable.ad_table_id = tab.ad_table_id<br /> join ad_window win on tab.ad_window_id = win.ad_window_id<br /> join ad_column col on fld.ad_column_id = col.ad_column_id<br /> left join ad_reference ref on col.ad_reference_id = ref.ad_reference_id<br /> left join ad_reference refvalue on col.ad_reference_value_id = refvalue.ad_reference_id<br /> left join ad_ref_table reftable on reftable.ad_reference_id = refvalue.ad_reference_id<br /> left join ad_table reftabletbl on reftabletbl.ad_table_id = reftable.ad_table_id<br /> where <br /> --upper(win.name) like upper('Window Name') and<br /> fld.isdisplayed = 'Y' and<br /> --upper(col.columnname) = upper('column_name') and<br /> --upper(fld.name) like upper('User column name')<br /> --upper(tabtable.tablename) = upper('tablename') and<br /> win.name in ( 'Window Name' ) --and <br /> --tab.seqno = 10<br /> order by win.name, tab.seqno, fld.seqno, col.columnname<br /> ;&lt;/nowiki&gt;<br /> <br /> == Windows referencing a specific process ==<br /> &lt;nowiki&gt;select name from ad_window where ad_window_id in (<br /> select ad_window_id from ad_tab where ad_process_id in (<br /> select ad_process_id from ad_process where value = 'processname')<br /> );&lt;/nowiki&gt;<br /> <br /> == Window ==<br /> &lt;nowiki&gt;select * from ad_window a<br /> where a.ad_window_id=id&lt;/nowiki&gt;<br /> <br /> == Tab ==<br /> &lt;nowiki&gt;select * from ad_tab a<br /> where a.ad_window_id=id&lt;/nowiki&gt;<br /> <br /> == Field ==<br /> &lt;nowiki&gt;select a.* from ad_field a<br /> join ad_tab b on a.ad_tab_id=b.ad_tab_id<br /> where b.ad_window_id=id&lt;/nowiki&gt;<br /> <br /> = Table =<br /> == Table ==<br /> &lt;nowiki&gt;select a.* from ad_table a<br /> where a.ad_table_id in (id, id)<br /> <br /> (select ad_table_id from ad_table where tablename='tablename')<br /> &lt;/nowiki&gt;<br /> <br /> = Table Columns =<br /> <br /> &lt;nowiki&gt;select a.name, a.columnname from ad_column a<br /> join ad_element b on a.ad_element_id=b.ad_element_id<br /> where a.ad_table_id in ((select ad_table_id from ad_table where tablename='tablename'))<br /> order by a.name;<br /> &lt;/nowiki&gt;<br /> <br /> = Callout =<br /> &lt;nowiki&gt;select a.ad_column_id,tbl.tablename, a.columnname,a.name, a.callout from ad_column a<br /> join ad_table tbl on a.ad_table_id = tbl.ad_table_id<br /> where a.callout is not null and a.callout like '%bPartner%'<br /> order by tbl.tablename, a.callout, a.name;&lt;/nowiki&gt;<br /> <br /> == Update callout ==<br /> <br /> &lt;nowiki&gt;update ad_column set callout = 'org.compiere.model.CalloutInvoiceNew.bPartner' where ad_column_id = 3499;&lt;/nowiki&gt;<br /> <br /> <br /> = References =<br /> &lt;nowiki&gt;select * from ad_ref_list where ad_reference_id in ( select ad_reference_id from ad_reference where name = 'Ref Name' );<br /> -<br /> Incomplete:<br /> left join<br /> ad_reference ref on ref.name = 'ZZ_Status'<br /> left join<br /> ad_ref_list reflist on reflist.ad_reference_id = ref.ad_reference_id and reflist.value = perm.zz_status&lt;/nowiki&gt;<br /> <br /> = Elements =<br /> &lt;nowiki&gt;select b.* from ad_column a<br /> join ad_element b on a.ad_element_id=b.ad_element_id<br /> where a.ad_table_id in (1000153, 1000152, 1000154, 1000156)&lt;/nowiki&gt;<br /> <br /> = Report and process =<br /> &lt;nowiki&gt;select * from ad_process order by created desc;<br /> <br /> select * from ad_process_para where ad_process_para_id = 1000000;<br /> <br /> select columnname, name, defaultvalue from ad_process_para where ad_process_id = 1000000 order by seqno;<br /> <br /> update ad_process_para set defaultvalue='1' where ad_process_id = 1000000 and columnname = 'columname'; --Sequence&lt;/nowiki&gt;<br /> <br /> = Delete fields from window =<br /> == Delete all fields on window ==<br /> &lt;nowiki&gt;delete from ad_field where ad_tab_id in ( select ad_tab_id from ad_tab where ad_window_id in <br /> (<br /> select ad_window_id from ad_window where name like 'Name of window' <br /> ) );&lt;/nowiki&gt;<br /> <br /> == Delete all fields on tab ==<br /> &lt;nowiki&gt;delete from ad_field where ad_tab_id in ( select ad_tab_id from ad_tab where name = 'tabname' and ad_window_id in <br /> (<br /> select ad_window_id from ad_window where name = 'Name of window' <br /> ) );&lt;/nowiki&gt;<br /> <br /> <br /> = Sequences =<br /> &lt;nowiki&gt;update ad_sequence a set CURRENTNEXTSYS =13000 where a.name = 'name';&lt;/nowiki&gt;<br /> <br /> = Doctype =<br /> <br /> &lt;nowiki&gt;select c_doctype_id from c_doctype where name = 'DocumentName'&lt;/nowiki&gt;<br /> <br /> = Delete all attachments of process =<br /> <br /> &lt;nowiki&gt;delete from ad_attachment where record_id in (<br /> select ad_process_id from ad_process where value like 'processname%' ) ...&lt;/nowiki&gt;<br /> <br /> = Synchronize Translations =<br /> <br /> An example:<br /> <br /> &lt;nowiki&gt;update ad_process_trl a set name = b.name, description = b.name from ad_process b where a.ad_process_id = b.ad_process_id and b.name = 'Process Name';&lt;/nowiki&gt;</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6804 2015-04-19T20:53:40Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There are two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6780 2015-03-25T17:50:51Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There two ways to install, Felix Console or P2 Repository.<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6779 2015-03-25T17:49:43Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> <br /> == How to Install ==<br /> There two ways to install:<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6778 2015-03-25T17:46:53Z

<p>Tioraul: /* P2 Repository */</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6777 2015-03-25T17:46:34Z

<p>Tioraul: /* P2 Repository */</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6776 2015-03-25T17:45:16Z

<p>Tioraul: /* Felix Console */</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[https://www.youtube.com/watch?v=oAQUK2FJBV0]<br /> <br /> === P2 Repository ===<br /> <br /> The recommended way to install the plugin is using the p2 repository.<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6775 2015-03-25T17:44:36Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === Felix Console ===<br /> <br /> watch this video (spanish)[watch this video]<br /> <br /> === P2 Repository ===<br /> <br /> The recommended way to install the plugin is using the p2 repository.<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=6302 2014-10-28T15:19:27Z

<p>Tioraul: </p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === P2 Repository ===<br /> <br /> The recommended way to install the plugin is using the p2 repository.<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> sudo java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=5674 2014-07-03T18:49:40Z

<p>Tioraul: /* P2 Repository */</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === P2 Repository ===<br /> <br /> The recommended way to install the plugin is using the p2 repository.<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository file://$REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:Available_Plugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Localizations&diff=4993 2013-12-16T15:11:00Z

<p>Tioraul: /* Chile */</p> <hr /> <div>== Colombia ==<br /> <br /> [[Image:Qss.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CarlosRuiz|Carlos Ruiz]] - [http://globalqss.com Quality Systems &amp; Solutions GlobalQSS]<br /> * '''Last Update:''' November 21, 2013<br /> * '''Status:''' Up to date with release 2.0<br /> * '''Download URL:''' [https://bitbucket.org/CarlosRuiz_globalqss/globalqss-idempiere-lco/downloads downloads]<br /> ** Plugins<br /> *** Nombres Detallados<br /> *** Medios Magnéticos<br /> *** Retenciones<br /> ** Datos<br /> *** Geografía Completa<br /> *** Geografía Capitales<br /> *** Festivos<br /> *** Datos Ejemplo Retenciones para GardenWorld<br /> *** Datos Ejemplo Medios Magnéticos para GardenWorld<br /> ** [[Translations#Colombia|Lenguage es_CO]]<br /> <br /> <br /> == Chile ==<br /> <br /> * [https://sourceforge.net/projects/adempierechile/files/GeografiaChileIdempiere.zip/download Geografía Completa con Comunas y Regiones]<br /> * [http://wiki.idempiere.org/en/Plugin:_LCL_Rut_Taxid Plugin Verificador RUT o CI chileno]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Localizations&diff=4992 2013-12-16T15:10:01Z

<p>Tioraul: </p> <hr /> <div>== Colombia ==<br /> <br /> [[Image:Qss.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CarlosRuiz|Carlos Ruiz]] - [http://globalqss.com Quality Systems &amp; Solutions GlobalQSS]<br /> * '''Last Update:''' November 21, 2013<br /> * '''Status:''' Up to date with release 2.0<br /> * '''Download URL:''' [https://bitbucket.org/CarlosRuiz_globalqss/globalqss-idempiere-lco/downloads downloads]<br /> ** Plugins<br /> *** Nombres Detallados<br /> *** Medios Magnéticos<br /> *** Retenciones<br /> ** Datos<br /> *** Geografía Completa<br /> *** Geografía Capitales<br /> *** Festivos<br /> *** Datos Ejemplo Retenciones para GardenWorld<br /> *** Datos Ejemplo Medios Magnéticos para GardenWorld<br /> ** [[Translations#Colombia|Lenguage es_CO]]<br /> <br /> <br /> == Chile ==<br /> <br /> * [https://sourceforge.net/projects/adempierechile/files/GeografiaChileIdempiere.zip/download Geografía Completa con Comunas y Regiones]<br /> * [http://wiki.idempiere.org/en/Plugin:_LCL_Rut_Taxid Verificador RUT o CI chileno]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Plugin:_LCL_Rut_Taxid&diff=4974 2013-12-16T02:09:23Z

<p>Tioraul: Created page with &quot; * '''Maintainer:''' Raul Vasquez * '''Status:''' Testing * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2] * '''Price:''' Free * '''Bitbucke...&quot;</p> <hr /> <div><br /> * '''Maintainer:''' [[User:Tioraul|Raul Vasquez]] <br /> * '''Status:''' Testing<br /> * '''License:''' [http://www.gnu.org/licenses/gpl-2.0.html GPLv2]<br /> * '''Price:''' Free<br /> * '''Bitbucket Repository:''' [https://bitbucket.org/raul_vasquez/lcl/src/488c4614acd4dca27e3bdee1a2195bdcbe8f2d44/VerificadorRutChile.zip?at=default#]<br /> * '''Zip file:''' VerificadorRutChile.zip<br /> * '''Sources:''' [https://bitbucket.org/raul_vasquez/lcl bitbucket]<br /> * '''On Feature:''' VerificadorRutChile.feature.group<br /> <br /> <br /> <br /> == Description ==<br /> <br /> This functionality adds chilean Tax Id RUT Verification on TaxID field<br /> <br /> <br /> == Feedback ==<br /> <br /> Please rate this plugin:<br /> <br /> {{#w4grb_rate:Plugin:_LCL_Rut_Taxid}}<br /> <br /> &lt;w4grb_ratinglist pagevotes idpage=&quot;Plugin:_LCL_Rut_Taxid&quot; items=&quot;30&quot;/&gt;<br /> <br /> <br /> If you want to provide additional comments, please use the [[Talk:Plugin:_LCL_Rut_Taxid|Discussion page]]<br /> <br /> == Configuration ==<br /> <br /> === SysConfig Parameters ===<br /> <br /> N/A<br /> <br /> == How to Install ==<br /> <br /> === P2 Repository ===<br /> <br /> The recommended way to install the plugin is using the p2 repository.<br /> <br /> Unzip VerificadorRutChile.zip<br /> <br /> <br /> DESTINATION=/opt/idempiere-server # Where your iDempiere server is installed<br /> REPO=/folder/where/you/unzip/VericadorRutChile.zip<br /> cd $DESTINATION<br /> java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director \<br /> -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director \<br /> -consoleLog -profileProperties org.eclipse.update.install.features=true \<br /> -destination $DESTINATION -repository $REPO \<br /> -i VerificadorRutChile.feature.group<br /> <br /> Replace the DESTINATION variable with the folder where your iDempiere server is installed.<br /> <br /> <br /> [[Category:AvailablePlugins]]</div>

Tioraul https://wiki.idempiere.org/w-en/index.php?title=Localizations&diff=4878 2013-12-06T02:53:19Z

<p>Tioraul: </p> <hr /> <div>== Colombia ==<br /> <br /> [[Image:Qss.jpg|right|160px]]<br /> * '''Maintainer:''' [[User:CarlosRuiz|Carlos Ruiz]] - [http://globalqss.com Quality Systems &amp; Solutions GlobalQSS]<br /> * '''Last Update:''' November 21, 2013<br /> * '''Status:''' Up to date with release 2.0<br /> * '''Download URL:''' [https://bitbucket.org/CarlosRuiz_globalqss/globalqss-idempiere-lco/downloads downloads]<br /> ** Plugins<br /> *** Nombres Detallados<br /> *** Medios Magnéticos<br /> *** Retenciones<br /> ** Datos<br /> *** Geografía Completa<br /> *** Geografía Capitales<br /> *** Festivos<br /> *** Datos Ejemplo Retenciones para GardenWorld<br /> *** Datos Ejemplo Medios Magnéticos para GardenWorld<br /> ** [[Translations#Colombia|Lenguage es_CO]]<br /> <br /> <br /> == Chile ==<br /> <br /> * [https://sourceforge.net/projects/adempierechile/files/GeografiaChileIdempiere.zip/download Geografía Completa con Comunas y Regiones]</div>

Tioraul