Orders & Invoicing – features worth noting

This map adds a communication judgement for each feature

How features are classified

  • Customer value: High = affects revenue, cash, stock accuracy or daily workload for many users. Medium = valuable in specific situations or segments. Low = convenience.
  • Differentiation: Distinctive = uncommon in comparable SME ERP/invoicing products, or done unusually completely. Strong = present elsewhere but notably well handled here. Standard = expected of any comparable product.
  • Discoverability:
    • Visible: shown in the normal flow.
    • Contextual: appears on the relevant document or state.
    • Configured: needs a module, setting or privilege, so users who have not enabled it will not see it.
    • Automatic: happens without a user action, so it is invisible unless explained.
    • Buried: present but easy to miss (terse or unlabelled control, separate menu, narrow precondition).
  • Communication tier:
    • Lead: headline candidates, grouped into the stories below.
    • Proof point: supports a story or a segment page.
    • Compliance: must-have regulatory capability, communicated as assurance rather than as differentiation.
    • Help & onboarding: worth teaching users, low marketing value.
    • Baseline: expected; list in the catalogue but do not lead with it.

These are product judgements made from the validated semantics, not market research. Differentiation in particular should be checked against current competitor offerings before external use.

Lead stories

Order fulfilment you can see

Orders that can be fulfilled in stages, combined into one document, and tracked line by line through to the documents that fulfilled them.

  • Lead features: Partial Order fulfilment; Order progress; Multiple Orders in one document; Resulting documents.
  • Proof points: Quotation, Proforma or Estimate to Order; Order to Invoice; Order to Delivery; Pending customer-order quantity.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Pending customer-order quantity (automatic)
  • Caveat — Multiple Orders in one document: Never advertise mixing Orders and Consignments in one selection.

Consignment stock, end to end

Goods placed with customers stay on the books as consigned stock until each unit is invoiced or returned, with the split always visible.

  • Lead features: Customer Consignment; Consignment invoicing; Consignment return; Consignment progress; Consignment invoiced/returned split; Multiple Consignments in one Invoice.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Customer Consignment (configured)
  • Caveat — Multiple Consignments in one Invoice: Never advertise mixing Orders and Consignments in one selection.

Invoice from the work already done

Invoices built from earlier documents instead of retyping them, without duplicate stock movements or double counting.

  • Lead features: Invoice several Quotations, Proformas or Estimates.
  • Proof points: Invoice a Delivery or Bill of Works; Invoice several Deliveries or Bills of Works; Create from a source document.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Invoice several Quotations, Proformas or Estimates (buried)
    • Invoice several Deliveries or Bills of Works (buried)
  • Caveat — Invoice several Quotations, Proformas or Estimates: Do not imply Consignments can be added through Document; invoicing an Order-derived Proforma does not fulfil the Order.

Buy for what customers ordered

Purchase suggestions calculated from outstanding customer demand, stock and pending supply.

  • Lead features: Purchase replenishment from customer demand.
  • Proof points: Pending customer-order quantity.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Pending customer-order quantity (automatic)

Billing on autopilot

One-to-one, per-customer and recurring contract billing in bulk, through the same validation and posting as manual invoices.

  • Lead features: Automated billing by document; Automated billing by customer; Recurring contract invoicing.
  • Proof points: Batch print, email and PDF.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Automated billing by document (configured)
    • Automated billing by customer (configured)
    • Recurring contract invoicing (configured)
    • Batch print, email and PDF (buried)

E-invoicing ready

Invoices sent over Peppol, with the national electronic formats covered.

  • Lead features: Peppol e-invoicing.
  • Proof points: UBL and CIUS-PT electronic invoice; JEDI, eSPap and SAF interchange.
  • Discoverability: these are not easy to find, so communication has to carry them:
    • Peppol e-invoicing (configured)
    • JEDI, eSPap and SAF interchange (configured)
  • Caveat — Peppol e-invoicing: Network delivery is external; describe sending and status, not guaranteed delivery.
  • Caveat — JEDI, eSPap and SAF interchange: Local sending/export; external protocol lifecycles are not audited.

High value, low discoverability

These are the strongest candidates for in-product help, onboarding and release notes, because users get significant value from them but are unlikely to find them unaided. Compliance and baseline features are excluded.

FeatureDiscoverabilityWhy it is missed
Credit limit and overdue blockingConfiguredOnly acts once limits are configured on the customer.
Customer ConsignmentConfiguredNeeds consignment enabled and a consignment series.
Invoice several Quotations, Proformas or EstimatesBuriedSits behind the compact Document button, which does not explain that item lines are copied.
Invoice several Deliveries or Bills of WorksBuriedSame Document button; nothing indicates that several documents can be combined.
Receipts for several documentsBuriedUses Document inside a new Receipt, which is not an obvious place to look.
Multibanco payment referencesConfiguredRequires provider and series configuration.
Customer price lists and discountsConfiguredNeeds multiple price lists or a discount grid to be enabled.
Automated billing by documentConfiguredSeparate Automated Billing menu, only with automation enabled.
Automated billing by customerConfiguredSeparate Automated Billing menu, only with automation enabled.
Recurring contract invoicingConfiguredSeparate contracts area, only with contracts enabled.
Peppol e-invoicingConfiguredRequires Peppol configuration and customer identifiers.

Full classification

FeatureValueDifferentiationDiscoverabilityTier
Orders and Invoicing work areasMediumStandardVisibleBaseline
Document search and browsingMediumStandardVisibleBaseline
DraftsMediumStandardVisibleHelp & onboarding
Document series configurationMediumStandardConfiguredBaseline
Reusable document commentsLowStandardContextualHelp & onboarding
Document data importMediumStrongConfiguredProof point
Sales, receipts and tax listingsMediumStandardVisibleBaseline
Listing print and CSV exportMediumStandardVisibleBaseline
Document composition and issueHighStandardVisibleBaseline
Article, service and text linesHighStandardVisibleBaseline
Customer, contact and addressesMediumStandardVisibleBaseline
Salesperson and operator attributionMediumStandardConfiguredHelp & onboarding
Project and resource associationMediumStrongConfiguredProof point
Customer–supplier order linkMediumStrongBuriedHelp & onboarding
Foreign-currency documentsMediumStandardConfiguredHelp & onboarding
Customer referenceLowStandardVisibleBaseline
Create from a source documentHighStandardContextualHelp & onboarding
Copy documentMediumStandardBuriedHelp & onboarding
Kits/packages in documentsMediumStrongConfiguredProof point
Dimension-based quantities (A×B)MediumDistinctiveConfiguredProof point
Option-combination surchargesMediumDistinctiveConfiguredProof point
Line sortingLowStandardBuriedHelp & onboarding
Credit limit and overdue blockingHighStrongConfiguredProof point
Edit, delete and void protectionMediumStandardContextualCompliance
Salesperson approval limitsMediumStrongConfiguredHelp & onboarding
Flexible order controlMediumStrongConfiguredHelp & onboarding
Quotation, Proforma or Estimate to OrderHighStandardContextualProof point
Order to InvoiceHighStandardContextualProof point
Order to DeliveryHighStandardContextualProof point
Partial Order fulfilmentHighStrongContextualLead
Order progressHighDistinctiveVisibleLead
Multiple Orders in one documentHighDistinctiveContextualLead
Pending customer-order quantityMediumStrongAutomaticProof point
Manual close and reopenMediumStandardContextualHelp & onboarding
Purchase replenishment from customer demandHighDistinctiveContextualLead
Customer ConsignmentHighDistinctiveConfiguredLead
Consignment invoicingHighDistinctiveContextualLead
Consignment returnHighStrongContextualLead
Consignment progressHighDistinctiveVisibleLead
Consignment invoiced/returned splitHighDistinctiveVisibleLead
Multiple Consignments in one InvoiceHighDistinctiveContextualLead
Resulting documentsHighDistinctiveVisibleLead
Document status check and repairMediumStrongContextualHelp & onboarding
Invoice, Invoice/Receipt and Cash SaleHighStandardVisibleBaseline
Invoice a Delivery or Bill of WorksHighStrongContextualProof point
Invoice several Quotations, Proformas or EstimatesHighDistinctiveBuriedLead
Invoice several Deliveries or Bills of WorksHighStrongBuriedProof point
Returns and credit returnsHighStandardContextualBaseline
Credit and debit notesHighStrongContextualProof point
Void, delete draft and void-and-replaceMediumStandardContextualBaseline
Partial paymentsHighStandardContextualProof point
Receipts for several documentsHighStrongBuriedProof point
Cash advances and payment returnsMediumStrongConfiguredProof point
Payment method, tendered amount and changeMediumStandardVisibleBaseline
Multibanco payment referencesHighStrongConfiguredProof point
Cashier shiftsMediumStandardConfiguredHelp & onboarding
Budget headingsMediumDistinctiveConfiguredProof point
Customer price lists and discountsHighStrongConfiguredProof point
Line discounts and global discountHighStandardVisibleBaseline
Cost and margin visibilityMediumStrongConfiguredProof point
VAT-inclusive or exclusive pricingHighStandardAutomaticCompliance
VAT exemption, customer tax data and OSSHighStandardAutomaticCompliance
Eco tax, stamp duty and withholdingMediumStrongConfiguredCompliance
Freight chargesMediumStandardVisibleBaseline
Second-hand goods and works of art margin schemeMediumDistinctiveConfiguredProof point
Fiscal signature and numbering controlHighStandardAutomaticCompliance
Tax-authority series codes (ATCUD)HighStandardConfiguredCompliance
Warehouses and stock availabilityHighStandardConfiguredBaseline
Serial numbers and lotsHighStandardConfiguredBaseline
Barcode labels from documentsMediumStandardConfiguredHelp & onboarding
Invoice now, deliver laterMediumStrongConfiguredProof point
Pick and transit documentsMediumStandardContextualHelp & onboarding
Courier and carrier shipmentsMediumStrongConfiguredProof point
Transport document communication (Portugal)HighStandardConfiguredCompliance
Automated billing by documentHighStrongConfiguredLead
Automated billing by customerHighStrongConfiguredLead
Batch receiptsMediumStrongConfiguredHelp & onboarding
Batch print, email and PDFMediumStandardBuriedProof point
Recurring contract invoicingHighDistinctiveConfiguredLead
Print and PDFHighStandardVisibleBaseline
Gift receipt printLowStandardConfiguredHelp & onboarding
Email documentsHighStandardContextualBaseline
UBL and CIUS-PT electronic invoiceHighStandardContextualCompliance
Peppol e-invoicingHighStrongConfiguredLead
JEDI, eSPap and SAF interchangeMediumStrongConfiguredCompliance
Webshop ordersMediumStrongConfiguredProof point
Repairs and RMAMediumStrongConfiguredProof point
Production documentsMediumStrongConfiguredProof point
Trade-insMediumDistinctiveConfiguredProof point

Rounding, VAT and Peppol

Rounding, VAT and Peppol: why one cent can make a difference

An invoice shows one total in an ERP system, while an e-commerce platform or accounting application arrives at a figure that differs by one cent. Which system is wrong?

In many cases, neither.

A one-cent difference may simply result from the point at which each system rounds prices, discounts, taxable amounts and VAT. With the increasing adoption of structured electronic invoicing — particularly through Peppol and models based on the European EN 16931 standard — these small differences are no longer merely a matter of presentation: they can determine whether or not a document is accepted by another system.

This is why Gestix totalises invoices within the ERP itself rather than delegating the calculation to the application communicating with the API.

An invoice is more than quantity × price + VAT

The calculation may appear simple:

Quantity × Price − Discounts + VAT = Total

In practice, several decisions have to be made along the way.

Does the price include VAT? Are there multiple successive discounts on the line? Is there an overall document discount? Is that discount a percentage or an amount? At what point should rounding take place? Is VAT calculated line by line or on accumulated amounts?

Two applications can use exactly the same prices, quantities, discounts and VAT rates and still arrive at slightly different totals.

A particularly interesting case occurs when prices already include VAT.

An example: €24.95 with a 30.63% discount

Consider one unit with:

  • VAT-inclusive price: €24.95
  • discount: 30.63%
  • VAT: 21%

After applying the discount, the gross line amount is:

24.95 × 0.6937 = €17.307815

Rounded to cents:

€17.31

To determine the corresponding taxable amount:

(24.95 × 0.6937) ÷ 1.21 = €14.303979…

Rounded to cents:

€14.30

The VAT amount for the line is then determined by the difference:

€17.31 − €14.30 = €3.01

It may seem like an insignificant detail. It is not.

If another application first rounds the gross amount and then recalculates VAT from that already-rounded figure, it may, in certain cases, arrive at a different result.

Multiply that difference across several invoice lines, different VAT rates, discounts and allowances, and it becomes easy to understand why two systems can disagree on the totals of the same invoice.

EN 16931 and the importance of line-level calculation

Structured electronic invoicing has made this issue particularly relevant.

The European EN 16931 standard, used throughout the European e-invoicing ecosystem and in Peppol implementations, defines a rigorous semantic model for the values that make up an invoice.

It is not enough for the final total simply to “look right”. Line amounts, taxable amounts, taxes, discounts and totals must be consistent with one another and comply with the validation rules applicable to the electronic document.

Gestix therefore uses a calculation model that transforms the document’s commercial data — including VAT-inclusive prices, discounts and allowances — into the net amounts, taxable amounts, taxes and totals required by the EN 16931 model and Peppol interoperability rules.

Under this model, each line is totalised individually, and the resulting rounded values are subsequently used to build the VAT subtotals and document totals.

This reduces one of the classic causes of one-cent discrepancies: using rounding strategies that differ from those required to maintain consistency between line amounts, taxable amounts, VAT subtotals and the totals required by the interoperability model.

Three line discounts are not a single discount

There is another frequent source of discrepancies in integrations.

Gestix can apply multiple successive discounts to an invoice line. These discounts are cumulative rather than additive.

For example, a 10% discount followed by a 5% discount does not amount to a 15% discount.

The calculation is:

0.90 × 0.95 = 0.855

The effective discount is therefore 14.5%.

This distinction is particularly important for integrations with online stores, commercial platforms and external applications that create documents through the Gestix API.

If the external system simply adds the percentages together, its calculated values will no longer match those of Gestix.

What about document-level discounts?

Discounts applied to the document as a whole add another dimension to the problem.

An overall discount may affect different taxable amounts when the document contains lines subject to different VAT rates. It is therefore necessary to determine correctly the portion of the discount associated with each VAT category and rate.

Under the EN 16931/Peppol model, document-level discounts are identified as such and taken into account when determining the taxable amount for the corresponding VAT category.

Internally, Gestix performs the calculations and adjustments necessary to preserve consistency between the document’s commercial values, taxable amounts, VAT subtotals and final total.

Where necessary, residual differences caused by rounding must also be handled in a controlled manner rather than simply disappearing or altering the intended document total.

The API provides the commercial data; Gestix calculates the totals

This leads to an important rule for applications integrating with Gestix.

An application creating an invoice through the API should primarily provide the commercial data from which the document is built: quantities, prices, discounts, VAT rates and any other applicable elements.

Invoice totalisation takes place on the Gestix server.

Once the document has been processed, the API returns the values actually calculated and persisted by the ERP, including the net amount, VAT, rounding and total.

This provides a single source of truth for the Gestix document.

The external application may, of course, perform its own calculations for display or verification purposes. It should not, however, assume that a calculation using a different rounding strategy will necessarily produce the same intermediate values.

ERP, API and Peppol speaking the same language

Interoperability is not merely about being able to transmit an XML file from one system to another.

Both systems must attribute the same meaning to the values contained in that file.

This is precisely why apparently minor questions such as when to round a cent matter in the evolution of Gestix.

Support for electronic invoicing and Peppol does not end with generating the electronic document. It starts earlier, with the calculation model that produces the values that will ultimately form part of that document.

By centralising invoice totalisation within the ERP and applying rules appropriate to different invoicing scenarios, Gestix aims to ensure that what is invoiced, what the API returns and what is transmitted electronically all represent the same commercial document.

Because in electronic invoicing, one cent is information too.

Arredondamentos, IVA e Peppol

Arredondamentos, IVA e Peppol: porque um cêntimo pode fazer a diferença

Uma fatura apresenta um total num ERP, mas o sistema de comércio eletrónico ou a aplicação de contabilidade chega a um valor diferente por um cêntimo. Qual dos sistemas está errado?

Em muitos casos, nenhum.

Uma diferença de um cêntimo pode resultar simplesmente do momento em que cada sistema arredonda os preços, os descontos, a base tributável e o IVA. Com a crescente utilização da faturação eletrónica estruturada — nomeadamente através de Peppol e de modelos baseados na norma europeia EN 16931 — estas pequenas diferenças deixaram de ser apenas uma questão de apresentação: podem determinar se um documento é ou não aceite por outro sistema.

É por isso que a totalização de uma fatura no Gestix é efetuada pelo próprio ERP e não delegada na aplicação que comunica com a API.

Uma fatura é mais do que quantidade × preço + IVA

O cálculo parece simples:

Quantidade × Preço − Descontos + IVA = Total

Na prática, há várias decisões pelo caminho.

O preço inclui ou não IVA? Existem vários descontos sucessivos na linha? Há um desconto global no documento? Esse desconto é uma percentagem ou um valor? Em que momento deve ser feito o arredondamento? O IVA é calculado linha a linha ou sobre valores acumulados?

Duas aplicações podem utilizar exatamente os mesmos preços, quantidades, descontos e taxas de IVA e, ainda assim, chegar a totais ligeiramente diferentes.

Um caso particularmente interessante ocorre quando os preços já incluem IVA.

Um exemplo: 24,95 € com 30,63% de desconto

Consideremos uma unidade com:

  • preço com IVA: 24,95 €
  • desconto: 30,63%
  • IVA: 21%

Depois do desconto, o valor bruto da linha é:

24,95 × 0,6937 = 17,307815 €

Arredondado aos cêntimos:

17,31 €

Para determinar a base tributável correspondente:

(24,95 × 0,6937) ÷ 1,21 = 14,303979… €

Arredondada aos cêntimos:

14,30 €

O IVA da linha fica então determinado pela diferença:

17,31 € − 14,30 € = 3,01 €

Parece um detalhe insignificante. Mas não é.

Se outra aplicação arredondar primeiro o valor bruto e voltar depois a calcular o IVA a partir desse valor já arredondado, pode chegar, em determinados casos, a um resultado diferente.

Multiplique-se essa diferença por várias linhas, diferentes taxas de IVA, descontos e abatimentos e é fácil perceber por que razão dois sistemas podem deixar de concordar sobre os totais de uma mesma fatura.

EN 16931 e a importância do cálculo ao nível da linha

A faturação eletrónica estruturada tornou esta questão especialmente relevante.

A norma europeia EN 16931, utilizada no ecossistema europeu de faturação eletrónica e em implementações Peppol, define um modelo semântico rigoroso para os valores que constituem uma fatura.

Não basta que o total final “pareça certo”. Os valores das linhas, bases tributáveis, impostos, descontos e totais têm de ser coerentes entre si e respeitar as regras de validação aplicáveis ao documento eletrónico.

O Gestix dispõe, por isso, de um modelo de cálculo que transforma os dados comerciais do documento — incluindo preços com IVA, descontos e abatimentos — nos valores líquidos, bases tributáveis, impostos e totais exigidos pelo modelo EN 16931 e pelas regras de interoperabilidade Peppol.

Nesse modelo, cada linha é totalizada individualmente e os respetivos valores arredondados são posteriormente utilizados na construção dos subtotais de IVA e dos totais do documento.

Isto reduz uma das causas clássicas das diferenças de um cêntimo: utilizar estratégias de arredondamento diferentes daquelas que permitem manter coerentes os valores das linhas, as bases tributáveis, os subtotais de IVA e os totais exigidos pelo modelo de interoperabilidade.

Três descontos de linha não são um único desconto

Há ainda outra fonte frequente de divergências nas integrações.

No Gestix podem existir vários descontos sucessivos numa linha. Estes descontos são cumulativos e não aditivos.

Por exemplo, um desconto de 10% seguido de outro de 5% não corresponde a um desconto de 15%.

O cálculo é:

0,90 × 0,95 = 0,855

Ou seja, o desconto efetivo é de 14,5%.

Esta distinção é particularmente importante nas integrações com lojas online, plataformas comerciais e aplicações externas que criam documentos através da API Gestix.

Se o sistema externo simplesmente somar as percentagens, os valores calculados deixarão de coincidir.

E os descontos globais?

Os descontos aplicados ao documento acrescentam outra dimensão ao problema.

Um desconto global pode afetar diferentes bases tributáveis quando o documento contém linhas sujeitas a diferentes taxas de IVA. É, por isso, necessário determinar corretamente a parte do desconto associada a cada categoria e taxa de IVA.

No modelo EN 16931/Peppol, os descontos ao nível do documento são identificados como tal e considerados no apuramento da base tributável da respetiva categoria de IVA.

Internamente, o Gestix efetua os cálculos e ajustamentos necessários para preservar a coerência entre os valores comerciais do documento, as bases tributáveis, os subtotais de IVA e o total final.

Quando necessário, diferenças residuais provocadas pelo arredondamento têm igualmente de ser tratadas de forma controlada, em vez de simplesmente desaparecerem ou alterarem o total pretendido.

A API envia os dados comerciais; o Gestix totaliza

Daqui resulta uma regra importante para quem integra aplicações com o Gestix.

Uma aplicação que cria uma fatura através da API deve enviar sobretudo os dados comerciais que dão origem ao documento: quantidades, preços, descontos, taxas de IVA e restantes elementos aplicáveis.

A totalização é efetuada no servidor Gestix.

Depois de processado o documento, a API devolve os valores efetivamente determinados e persistidos pelo ERP, incluindo a base líquida, IVA, arredondamentos e total.

Desta forma, existe uma única fonte de verdade para o documento Gestix.

A aplicação externa pode naturalmente efetuar os seus próprios cálculos para apresentação ou conferência. Mas não deve assumir que um cálculo efetuado com uma estratégia de arredondamento diferente terá necessariamente de produzir os mesmos valores intermédios.

ERP, API e Peppol a falar a mesma linguagem

A interoperabilidade não consiste apenas em conseguir transmitir um ficheiro XML de um sistema para outro.

É necessário que ambos atribuam o mesmo significado aos valores que estão dentro desse ficheiro.

É precisamente por isso que questões aparentemente tão pequenas como quando arredondar um cêntimo assumem importância na evolução do Gestix.

O suporte de faturação eletrónica e Peppol não termina na geração do documento eletrónico. Começa antes disso, no modelo de cálculo que produz os valores que irão integrar esse documento.

Ao centralizar a totalização no ERP e aplicar regras adequadas aos diferentes cenários de faturação, o Gestix procura assegurar que aquilo que é faturado, aquilo que a API devolve e aquilo que é transmitido eletronicamente representam o mesmo documento comercial.

Porque, em faturação eletrónica, um cêntimo também é informação.

Gestix ERP 2026: Peppol, Trade-Ins, API and Functional Improvements

Throughout 2026, Gestix ERP continued to receive functional and technical improvements aimed at strengthening platform stability, addressing new legal and operational requirements, and simplifying the everyday tasks performed by businesses.

Among the most significant developments was the launch, last April, of the Gestix ERP integration with the Peppol network. This represented an important milestone in the platform’s evolution towards faster, more secure and interoperable electronic invoicing.

Users can now also retrieve exchange and conversion rates directly from the Currencies menu, allowing exchange rate information to be updated in a simpler and more centralised way.

Exchange Rate Updates via Web Service

In addition to these new features, several functional improvements were made to existing areas of the application.

When issuing invoices and sales orders, users can now view the gross profit margin, providing better visibility into the profitability of documents while they are being prepared.

Gross Profit Analysis on Invoices

A total units calculation was also added to sales orders and invoices, making it easier to obtain an overall view of each document and monitor the quantities entered.

Information on Invoiced, Ordered and Fulfilled Units

When creating a customer directly from an invoice, it is now possible to assign attributes to the new customer, ensuring a more complete customer record from the moment it is created.

Another important improvement is the ability to retrieve customer information using the VAT identification number for European entities. This helps speed up data entry and reduces the need for information to be entered manually.

An edit and update history has also been introduced in the item record, improving the traceability of any changes made.

Change History in the Item Record

For businesses that regularly invoice the same service, such as taxi operators, Uber drivers and similar service providers, Gestix now supports the automatic entry of a predefined service when issuing an invoice, simplifying the invoicing process.

In terms of integration with external systems, the Gestix API now supports multiple simultaneous transactions, improving responsiveness in high-volume or continuous integration scenarios.

It is also now possible to increase the maximum length of item and service descriptions to 60 characters through the Parameters menu. For further information about this configuration, please contact Gestix Technical Support.

These improvements form part of the ongoing development of Gestix ERP, with the aim of responding to users’ needs, improving existing processes and preparing the platform for new digital integration and communication requirements.

Gestix ERP 2026: Peppol, Retomas, API e Melhorias Funcionais

Durante 2026, o Gestix ERP continuou a receber melhorias funcionais e técnicas, com o objetivo de reforçar a estabilidade da plataforma, acompanhar novas necessidades legais e operacionais, e simplificar tarefas frequentes no dia a dia das empresas.

Entre as novidades mais relevantes, destaca-se a entrada em produção, em abril último, da integração do Gestix ERP com a rede Peppol, um marco na evolução da plataforma para uma faturação eletrónica mais rápida, segura e interoperável.

Foi também introduzida a possibilidade de obtenção de taxas de câmbio/conversão diretamente no menu Moedas, permitindo atualizar informação cambial de forma mais simples e centralizada.

Atualização de taxas de câmbio via Webservice

Na área das retomas, foram igualmente desenvolvidas melhorias específicas, permitindo agora ao Gestix suportar o registo de compra de equipamentos no contexto de uma venda, bem como situações de compra de equipamentos sem venda associada.

Além destas novidades, foram realizados vários melhoramentos funcionais em áreas já existentes da aplicação.

Na emissão de faturas e encomendas, passou a ser possível visualizar a margem de lucro bruta, permitindo ao utilizador acompanhar melhor a rentabilidade dos documentos em preparação.

Análise de lucro bruto em faturas

Foi também acrescentado o somatório das unidades em encomendas e faturas, facilitando a leitura global dos documentos e o controlo das quantidades registadas.

Informação sobre unidades faturadas, encomendadas e satisfeitas

No processo de criação de clientes diretamente a partir da fatura, foi adicionada a possibilidade de associar atributos ao novo cliente, tornando o registo mais completo logo no momento da criação.

Outra melhoria importante é a obtenção de dados de cliente por NIF para entidades europeias, permitindo agilizar o preenchimento de informação e reduzir introduções manuais.

Na ficha do artigo, foi introduzido o histórico de edição/atualização, reforçando a rastreabilidade das alterações efetuadas.

Histórico de alterações na ficha do artigo

Para atividades em que é comum faturar sempre o mesmo serviço, como Táxi, UBER e outros serviços semelhantes, foi criada a possibilidade de preenchimento automático do serviço na emissão da fatura, simplificando o processo de faturação.

Ao nível da integração com sistemas externos, a API Gestix passou a permitir múltiplas transações simultâneas, melhorando a capacidade de resposta em cenários de maior volume ou integração contínua.

Foi ainda disponibilizada a possibilidade de aumentar o tamanho da descrição de artigos e serviços até 60 caracteres, através do menu Parâmetros. Para mais informação sobre esta configuração, contacte o Apoio Técnico Gestix.

Estas melhorias fazem parte do trabalho contínuo de evolução do Gestix ERP, procurando responder às necessidades dos utilizadores, melhorar processos existentes e preparar a plataforma para novos requisitos de integração e comunicação digital.

Como Adicionar um Atributo ao Criar um Cliente Diretamente na Fatura no Gestix

Adicionar checkbox newsletter

Em alguns cenários, pode ser necessário garantir que determinada informação fica associada ao cliente logo no momento da emissão da fatura.

No Gestix, isto pode ser feito através da utilização de Atributos de Cliente, permitindo apresentar um novo campo/opção ao criar um cliente diretamente numa Fatura.

Neste exemplo, vamos mostrar como configurar um atributo para ser preenchido durante a criação do cliente na fatura.

O que este procedimento permite?

Ao configurar um atributo com a opção “Ativo no POS”, o Gestix passa a disponibilizar esse atributo quando um novo cliente é selecionado, na emissão de uma fatura ou documento similar.

Isto pode ser útil para:

  • Identificar tipos específicos de clientes
  • Recolher consentimentos ou autorizações
  • Classificar clientes automaticamente
  • Criar regras internas de segmentação
  • Validar informação obrigatória no momento da venda

Passo 1 — Criar o Atributo

Primeiro, deverá criar o atributo a disponibilizar ao emitir a fatura.

No menu Clientes, opção Atributos

Selecione Novo

  • Defina o Nome do Atributo
  • Selecione Disponível no POS
  • Grave no Final

“Disponível no POS”, Esta opção é fundamental para que o atributo fique disponível no processo de criação rápida de clientes durante a faturação.

Passo 2 — Criar um novo Cliente na Fatura

Depois do atributo criado:

  1. Abrir um novo documento de faturação, neste caso vamos usar uma Fatura Simplificada
  2. Criar um Novo Cliente, ou selecionar um Cliente já existente no Gestix
  3. No caso de novo Cliente, preencher os dados do cliente e gravar
  1. Verificar que o novo atributo aparece disponível
  2. Marcar o respetivo visto
  1. Inserir as linhas da fatura
  2. Gravar a fatura

Durante este processo, se o atributo for marcado com um “visto”, ficará associado automaticamente ao cliente selecionado

Passo 3 — Confirmar o atributo no Cliente

Após gravar a fatura:

  1. Abrir a ficha do cliente criado
  2. Verificar os atributos do cliente
  3. Confirmar que o novo atributo ficou corretamente marcado

Resultado Final

Com esta configuração, o Gestix passa a permitir que determinados atributos sejam preenchidos logo no momento da criação da fatura ou documento similar.

Esta funcionalidade ajuda a:

  • Melhorar a qualidade dos dados
  • Garantir preenchimentos obrigatórios
  • Automatizar classificações internas

Se necessário, a equipa de suporte Gestix encontra-se disponível para qualquer esclarecimento adicional através do email suporte@gestix.com ou do telefone 919844655.

Obtenha os dados da empresa através do NIF

Esta opção, disponível ao emitir uma fatura ou documento similar, permite obter os dados do cliente empresarial por consulta da base de dados europeia de sujeitos passivos VIES.

Validação de NIF – Nº de Id. Fiscal – no Gestix

No Gestix, validamos NIFs de empresas europeias através do serviço VIES da Comissão Europeia. Porém, a lei da Proteção de Dados vigente impõe uma limitação importante: o VIES não identifica os dados de sujeitos particulares.

Limitações

O VIES (VAT Information Exchange System) é uma base de dados de sujeitos passivos de IVA registados para comércio intracomunitário. Em Portugal, isso inclui empresas e trabalhadores independentes registados em IVA — mas nunca particulares. Um NIF que comece por 1, 2 ou 3 (cidadãos residentes) jamais aparecerá no VIES. Se for consultado, o serviço devolve sempre “inválido”, o que não significa que o NIF esteja errado: significa apenas que não está registado para IVA.

Como são validados NIF de particulares

Validação por dígito de controlo. O NIF português tem 9 dígitos e usa um algoritmo módulo 11. Esta verificação interna facultada pelo Gestix apanha praticamente todos os erros de digitação — que, na prática, são a esmagadora maioria dos problemas reais. Não confirma que o NIF está atribuído a alguém, mas confirma que é matematicamente válido.

Como obter dados do cliente empresarial por NIF

Ao fazer uma fatura ou encomenda, digite o NIF no respetivo campo e prima o símbolo € à direita.

O Gestix efetua o pedido de informação em tempo real e apresenta o resultado, permitindo criar o cliente se não existir, e, caso contrário, comparar os dados obtidos com os existentes.

Para mais informação, contacte o Suporte Técnico Gestix

Fecho de Produção direto a partir de Modelo de Produto

O presente exemplo inspira-se no cenário seguinte: componentes provenientes da reparação de equipamentos eletrónicos são recuperados e injetados em stock, para posteriormente serem utilizados em novas reparações.

O processo de produção consome apenas mão de obra: por esta razão, é possível saltar o processo intermédio de criar Ordem de Produção, já que não existe movimento de stock na fase anterior ao Fecho de Produção.

Uma vez concluído o processo, os produtos estão prontos para entrar no stock com a designação “Vidro Teste Limpo”.

Os passos seguintes descrevem as operações a desenvolver pelo utilizador, no menu Ordens de Produção.

1. No menu Artigos, criar a ficha do Artigo destinado ao produto final (Tipo: Produto)

2. Definir o Modelo de Produto. Trata-se da “receita” que indica, para uma unidade de produto final, o consumo de materiais e serviços envolvidos – menu Ordens de Produção.

Nota: a criação da ficha de Artigo e a criação do Modelo de Produto são realizadas uma única vez. O Modelo de Produto é utilizado todas as vezes que se queira produzir o produto final Vidro Teste Limpo.

3. Criar o Fecho de Produção diretamente a partir do Modelo de Produto – este passo é realizado tantas vezes quantas seja necessário, sem necessidade de criar novo Modelo de Produto.

É indicada a quantidade a produzir e o Armazém ou local de armazenagem do produto final produzido.

Após acionado o botão Gravar, o stock do Produto (VIDRO TESTE LIMPO) é objeto de movimento de entrada no armazém selecionado no Fecho de Produção, e contabilizado ao custo definido no processo.

Criar Novas Séries de Faturação

Não sendo de todo obrigatório fazê-lo ao mudar o ano, pode criar novas Séries de Faturação, para começar a utilizar a qualquer momento, no menu Faturação / Séries de Documentos, clicando no botão +


Após inserir o indicativo da Série de Documentos, pode rever as restantes opções (separadores Geral e Imprimir) de forma a manter a configuração das séries que atualmente utiliza.


Clique em gravar, e pronto. A comunicação da série à AT e obtenção do respetivo Código de Validação será efetuada automaticamente no momento da emissão do primeiro documento daquela série.


Também poderá obter de imediato o Código de Validação, clicando no botão “Obter” após gravar a Série.

Ilustração dos passos a efetuar:


Abrir o menu Séries de Documentos

Clicar no botão +

Escolher o tipo de documento,

Preencher/verificar a informação e clicar Gravar.

Resultado final – Série pronta a utilizar.

Em caso de dúvida contacte o suporte Gestix via support @ gestix . com

Comunicação automática do ficheiro SAF-T

No menu Auditoria/SAFT, terá várias opções, conforme ilustrado na imagem em baixo.

Passo 1: Selecionar as datas referentes ao mês do ficheiro pretendido e carregar no botão Extrair SAFT.

Passo 2: Um novo ficheiro será gerado. Na coluna Ação, encontrará várias opções:

  • Descarregar – Permite descarregar o ficheiro para o seu PC
  • Enviar Mail – Envia o ficheiro por email
  • Verificar – Verifica o ficheiro para erros através do verificador oficial da AT
  • Enviar – Envia o ficheiro diretamente para a AT