$ 281.62
In-App Purchases| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Inventory (stock)
• Discuss (mail) • Invoicing (account) • Contacts (contacts) |
| Community Apps Dependencies | Show |
| Lines of code | 884 |
| Technical Name |
l10n_pe_delivery_note_20 |
| License | OPL-1 |
| Website | https://www.ganemo.com |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Inventory (stock)
• Discuss (mail) • Invoicing (account) • Contacts (contacts) |
| Community Apps Dependencies | Show |
| Lines of code | 884 |
| Technical Name |
l10n_pe_delivery_note_20 |
| License | OPL-1 |
| Website | https://www.ganemo.com |
Electronic Delivery Note
Advanced Peruvian Logistics & SUNAT Compliance
Master complex transfer scenarios. Handle multi-branch warehouses, returns, imports/exports, and third-party logistics with full SUNAT validation.
What We're Solving
----------------
Multi-Branch & Annex Codes
Stop guessing address codes. The system automatically identifies the correct Annexed Establishment (e.g., 0001) for every source and destination, ensuring seamless transfers between your own locations without SUNAT errors.
Full Catalog 20 Support
Go beyond basic sales. Handle every SUNAT-compliant transfer reason including Returns (06), Pickups (07), Imports (08), Exports (09), and customized logic for complex third-party logistics operations.
Smart 'Others' Management
Avoid SUNAT penalties. The native module sends a generic "Others" tag, but we inject your custom description (e.g., "Samples", "Gifts") directly into the XML, satisfying the strict requirement for specific implementation of Transfer Reason 13.
Third-Party Logic Fixes
We fix native gaps. Standard Odoo misses the
SellerSupplierParty tag for Incoming 'Others' transfers. We automatically
inject the correct Buyer/Seller parties based on the context, ensuring your XML is never
rejected for missing actors.
Internal Transfers (Same Company)
Seamlessly move goods between your own warehouses. The system correctly handles the logic where the Sender and Receiver are the SAME company (same RUC) but different Establishment Codes, a common scenario that often fails in standard setups.
Setup & User Manual
Step-by-Step implementation
1. Configuration Guide
Follow these steps to ensure full compliance and avoid blocking errors:
1.1 Configure Warehouse Addresses (Critical)
To prevent the "No se enviará la GRE..." error for Internal, Incoming, or Outgoing transfers:
- Go to Inventory > Configuration > Locations.
- Open your Warehouse locations (e.g., WH/Stock).
- Action: Set the Address field
(
direction_id). - Why? The module uses this specific address to determine the correct Annex Code (Establecimiento Anexo) for the XML.
1.2 Electronic Guide Sequences
- Go to Inventory > Configuration > Settings.
- Ensure you have a valid Sequence configured for "Guía de Remisión Remitente" (e.g., T001).
- On the Transfer form, this will appear in the Electronic Guide Sequence field.
1.3 Enable Test Environment (Sandbox)
- Go to Accounting / Inventory > Configuration > Settings.
- Locate the Peruvian Electronic Delivery Note section.
- Check "Entorno de prueba GRE".
- Effect: This directs all XML submissions to the Nubefact Test API instead of SUNAT Production.
2. Operating Manual (Workflow)
How to emit a compliant GRE:
1. Create Transfer
Create a standard Delivery Order or Internal Transfer. Select the partner and lines.
2. Define Logistics Data
In the "Guía de Remisión" tab:
- Reason: Select from Catalog 20 (e.g., Sale, Import, Return).
- Transport Mode: Public (3rd party) or Private (Own).
- Sequence: Select your T001 series.
3. Validation & Sending
Click Validate. The system generates the number (e.g., T001-000005) and attempts to sign/send the XML. Status changes to "Sent" or "Error".
4. Print & Corrections
Download the PDF. If SUNAT rejects it, check the "Error SUNAT" field, correct the data (e.g., Driver License), and click "Retry".
Critical: Handling "Others" (Code 13)
According to our deep analysis of the native module vs. this extension, using this module is mandatory for compliant "Others" transfers.
1. Transfer Reason Description
- Native Odoo: Sends the literal word "Others". This is risky because SUNAT requires a specific reason.
- This Module: Enables the "Transfer Reason Description" field. You can type "Muestras", "Obsequios", etc., ensuring the XML matches strict SUNAT requirements.
2. Buyer/Seller Logic
- Native Odoo: Only adds
BuyerCustomerParty, and does it indiscriminately for all "Others" cases. - This Module: INTELLIGENTLY manages parties:
- Adds
SellerSupplierPartyfor Incoming transfers (Native ignores this). - Uses the "Deliver to Third Parties" checkbox to control exactly when to send these tags, satisfying complex logistics flows.
- Adds
3. Technical Detail: XML Address Handling
How the system fills the crucial <cbc:AddressTypeCode>
tag.
The logic in edi_delivery_guide.xml
evaluates 3 main scenarios. In all cases, the
<cbc:AddressTypeCode> is filled ONLY if the address owner's
RUC starts with '6' (Legal Entities/Companies).
1. Source Address (cac:DespatchAddress)
Where does the merchandise come from?
| Scenario | Condition (Odoo) | Source of Annex Code |
|---|---|---|
| Return | l10n_pe_edi_reason_for_transfer == '06' |
Partner of the document (record.partner_id) |
| Third Party Delivery | deliver_to_third_parties is True |
In: Customer
(record.customer_id)Out: Origin Location ( record.location_id.direction_id)
|
| Standard | (None of the above) |
Out/Int: Origin Location
(record.location_id.direction_id)In: Partner (Vendor) ( record.partner_id)
|
2. Destination Address (cac:DeliveryAddress)
Where does the merchandise arrive?
| Scenario | Condition (Odoo) | Source of Annex Code |
|---|---|---|
| Return | l10n_pe_edi_reason_for_transfer == '06' |
Partner of the document (record.partner_id) |
| Third Party Delivery | deliver_to_third_parties is True |
In: Destination Location
(record.location_dest_id.direction_id)Out: Customer ( record.customer_id)
|
| Standard | (None of the above) |
In/Int: Destination Location
(record.location_dest_id.direction_id)Out: Partner (Customer) ( record.partner_id)
|
Practical Example: Standard Sale (Out)
Case: You sell goods to a customer from your Main Warehouse.
- Departure: Takes code from YOUR warehouse
(
location_id.direction_id), because it's a standard outgoing shipment. - Arrival: Takes code from the CUSTOMER
(
partner_id), because it's a standard outgoing shipment.
Crucial: Both your warehouses (address type partners) and your customers must have this field available.
Global Ready | Multi-Language Support
This module is fully translated into English and Spanish (en_US, es_ES, es_PE, es_MX), ensuring a professional experience for international organizations.
Why Choose Ganemo?
----------------
Ganemo is the world's leading Odoo App developer and a multi-award-winning Gold Partner. For over 5 years, we have been recognized as the #1 seller of high-quality apps on the Odoo App Store. Trusted as the "Best Partner" in USA, Mexico, Chile, Spain, Colombia, Ecuador, and Peru, we deliver robust, secure, and localization-compliant solutions for global businesses.
Get a Quote & Resolve Commercial Doubts
Join thousands of satisfied clients on Odoo. Contact our sales team directly.
Official WhatsApp
Fastest response time.
LINK
+1 (828) 672-6150
Book a Demo
Let's explore your needs.
LINK
Schedule Meeting
Need More? We Do It All
Professional Odoo Services
ERP Implementation
Transform your business with a full Odoo implementation. We analyze, configure, and train your team to maximize productivity. From Accounting to Inventory, we handle the complexity so you can focus on growth.
Module Dev & Migration
Need a custom feature? Or stuck on an older version? We develop high-performance custom modules and migrate your existing code to Odoo 19 with zero data loss. Expert developers at your service.
QA / User Testing Scenarios
Enterprise Validation Plan
Scenario 1: Multi-Branch Return
- Setup two branches with different Annex Codes (e.g., 0001, 0002) in Contacts.
- Create a Transfer from Branch A (0001) to "Supplier X" with Reason "Devolución" (06).
- Test: Validate the Transfer.
- Result: The generated XML MUST contain the tag
Codewith "0001" for the Issuer, ensuring SUNAT knows exactly where the goods left from.
Scenario 2: Import Delivery (Private Transport)
- Create a Transfer for incoming goods (Import).
- Select Reason "Importación" (08).
- Set Transport Type to "Private" and assign a Vehicle/Driver.
- Test: Validate and check the XML.
- Result: The system identifies this as an Import operation and correctly structures the delivery note, ignoring standard sale validations.
Scenario 3: Internal Transfer (Same Company)
Context: Moving goods from Main Warehouse (0000) to Store 1 (0001).
- Create Internal Transfer.
- Reason: "Traslado entre establecimientos" (04).
- Result: The XML correctly identifies both Source and Destination as the SAME company RUC but different Establishment Codes.
Scenario 4: Missing Code Validation
- Remove the "Address" (Direction) from a Stock Location (e.g., WH/Stock).
- Try to validate a delivery from that location.
- Result: The system MUST raise a UserError: "No se enviará la GRE hasta que no se configure el campo 'dirección'...". This confirms the safety guard is active.
Scenario 5: Verify Supply Chain Codes
Goal: Ensure critical Peruvian transfer reasons are available in the native Odoo field.
- Open any Delivery or Receipt operation.
- Click on the "Transfer Reason" dropdown.
- Verify the presence of these specific codes:
- 02: Compra
- 06: Devolución
- 07: Recojo de bienes transformados
- 08: Importación
- 09: Exportación
- Result: All codes must be selectable. If missing, the module data was not loaded correctly.
Scenario 6: Verify Handling Instructions Visibility
Goal: Ensure the description field appears only when needed.
- Create a new Delivery Note.
- Select "Others" (13) in "Reason for Transfer".
- Verify: The "Transfer Reason Description" field appears.
- Enter a description.
- Change "Reason for Transfer" to "Sale" (01).
- Verify: The "Transfer Reason Description" field disappears.
Scenario 7: Validate 'Others' XML Logic
Goal: Confirm that custom descriptions and special party tags are correctly injected into the XML.
- Create a Transfer with Reason "Others" (13).
- Write "Muestras Gratuitas" in the "Transfer Reason Description" field.
- Validate the document.
- XML Verification:
- The text "Muestras Gratuitas" MUST appear in the
<cbc:HandlingInstructions>tag (or equivalent description field). - If Incoming: Verify
<cac:SellerSupplierParty>is PRESENT. - If Outgoing: Verify
<cac:BuyerCustomerParty>is PRESENT.
- The text "Muestras Gratuitas" MUST appear in the
FAQ & Troubleshooting
Common Resolutions
Error: "No se enviará la GRE..."?
Reason: The Stock Location (Source or Destination) is missing the linked Address.
Fix: Go to Configuration > Locations, open the location, and set the Address field.
Can I test without sending to SUNAT?
Answer: Yes, checking the "Entorno de prueba GRE" in Settings will direct everything to the Nubefact Test API.
Tip: This is perfect for verifying XML generation logic without legal implications.
How to handle "Others" (Reason 13)?
Requirement: SUNAT requires a description.
Tip: Selecting "Others" automatically reveals the "Transfer Reason Description" field. Fill it to avoid rejection.
Is this Odoo 19 Compatible?
Answer: Yes!
Detail: Fully tested on Odoo 19 Enterprise. Supports latest SUNAT 2.0 electronic invoicing standards.
Commercial & Sales
For inquiries about licenses, demos, or partnerships.
Official WhatsApp
Fastest response time.
LINK
+1 (828) 672-6150
Book a Demo
Let's explore your needs.
LINK
Technical Support
Existing customers regarding module functionality.
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module