Introdução
A plataforma GissOnline é um sistema de escrituração eletrônica de Notas Fiscais de Serviço (NFS-e) usado por muitas prefeituras. Ela oferece Web Services SOAP baseados no padrão ABRASF (versões 2.03/2.04) para emissão, consulta, cancelamento e substituição de NFS-e. Cada município configura seu próprio portal GissOnline (ex.: https://ws-{MUNICÍPIO}.giss.com.br/service-ws/nf/nfse-ws?wsdl), e o acesso aos WSDLs exige certificado digital ICP-Brasil (SSL handshake). Em resumo, não há API REST pública, mas sim serviços SOAP oficiais por município, o que demanda integração específica (certificados, endpoints e layouts variam por prefeitura).
Alternativas de Captura Automática
Web Scraping / RPA
- Robôs ou scripts (Selenium, Puppeteer, UIPath etc.) simulam acesso ao portal GissOnline via login e navegação, extraindo XML/PDF das NFS-e.
- Essa abordagem dispensa API oficial, mas é frágil – depende da interface de cada prefeitura (tickets, CAPTCHAs, sessões) e requer manutenção constante.
- Soluções de RPA podem cobrir cidades sem API padronizada: por exemplo, ferramentas como “NFSe Full” usam tecnologia RPA para consultar NFS-e em qualquer prefeitura do país.
Integração por Serviços Terceirizados
- Serviços de mercado que coletam NFS-e automaticamente, como o NFSe Connect (via webservices diretos) e o NFSe Full (via RPA).
- Plataformas como Qive oferecem soluções completas de coleta automática nacional.
- Alternativas como Arquivei NFS-e, Nota Paraná, etc. agregam notas de diversos portais municipais, mas geralmente possuem cobertura limitada ou custo extra.
E-mail e Portais Municipais
- Métodos mais manuais: depender do envio de e-mail pelos prestadores ou consultar manualmente cada portal da prefeitura.
- São opções tediosas e sujeitas a falhas (perda de e-mail, instabilidade de sites), recomendadas apenas para volumes muito baixos.
Em suma, além do SOAP oficial, o caminho prático costuma ser automação via RPA/scripts ou uso de ferramentas especializadas. O uso de RPA permite atender prefeituras sem API, mas exige investimento em desenvolvimento; já serviços prontos custam mensalidade.
Importação de NFS-e no OMIE
Importação Manual via XML
- No módulo “Serviços e NFS-e” do OMIE, há opção de importar arquivos XML (ou ZIP de vários XML) de NFS-e de saída já emitidas.
- Para funcionar, o XML importado deve conter CNPJ, estado, município e inscrição municipal compatíveis com os dados cadastrados no OMIE.
- Caso a prefeitura ainda não tenha integração direta no OMIE, o usuário deve solicitar suporte fornecendo um XML de exemplo.
API OMIE (Contas a Pagar)
- Para NFS-e de entrada (recebidas), pode-se usar as APIs financeiras do OMIE.
- O serviço “Contas a Pagar – Lançamentos” permite criar/editar/consultar títulos a pagar.
- É possível registrar uma NFS-e como conta a pagar, informando fornecedor, valores, data, etc., e anexar o XML ou PDF da nota (via API de Documentos Anexos).
Documentos Fiscais e Webhooks
- OMIE possui módulos de “Documentos Fiscais” e webhooks, mas focados em notas emitidas pela própria empresa.
- Para notas de serviço recebidas, o processo recomendado é criar um título a pagar.
Assim, a integração técnica típica seria: obter o XML da NFS-e (via SOAP ou RPA) → usar a API “Contas a Pagar – Lançamentos” do OMIE para cadastrar o título, vinculando o XML como anexo.
Restrições e Particularidades Municipais
- Endereço do Serviço: Cada município possui um WSDL distinto (
https://ws-{MUNICIPIO}.giss.com.br/service-ws/nf/nfse-ws?wsdl). - Certificado Digital: A maioria dos webservices exige certificado ICP-Brasil para comunicação, inclusive para download do WSDL.
- Versão de Layout: Muitas prefeituras ainda utilizam versões antigas do padrão ABRASF ou layouts customizados. A padronização nacional (NFSe Nacional) é opcional e muitas cidades não aderiram.
- RPS e Lotes: Algumas cidades exigem emissão via RPS em lotes assíncronos, outras permitem emissão síncrona.
- Limitações de Cada Prefeitura: Pode haver exigência de cadastro prévio, instabilidade no portal ou ausência de webservice padrão.
Em resumo, não há solução única: cada prefeitura pode ter requisitos de certificado, formatos XML e até processos de autorização distintos.
Comparação de Opções
| Método | Vantagens | Desvantagens | Exemplos/Notas |
|---|---|---|---|
| Webservice SOAP (GissOnline) | Dados oficiais e completos (ABRASF v2.03/2.04); integração padronizada por prefeitura. | Requer certificado ICP-Brasil; cada URL é municipal; configuração complexa. | Viável apenas se o município permite integração SOAP. |
| RPA / Web Scraping | Não depende de API; cobre qualquer portal GissOnline. | Fragilidade por mudanças de interface; exige manutenção. | Ferramentas como NFSe Full para consultas nacionais. |
| Serviços Terceirizados | Abstrai complexidade de integração. | Custo mensal; cobertura variável. | Plataformas como NFSe Connect e Qive. |
| Consulta Manual | Baixo custo inicial. | Trabalho manual intenso; alta probabilidade de erros. | Útil apenas em volumes muito baixos. |
Exemplos de Uso / Casos Reais
- Empresas de tecnologia fiscal e escritórios contábeis utilizam APIs próprias (como as da Qive) para automatizar a coleta de NFS-e de qualquer prefeitura.
- Escritórios podem desenvolver scripts em Python ou usar Robôs de Automação (RPA) para logar em GissOnline e baixar XMLs periodicamente.
- No OMIE, é possível integrar via API de “Contas a Pagar”, criando lançamentos com a NFS-e como anexo, ou importar manualmente XMLs de notas emitidas.
Conclusão
Embora não exista uma integração “one-click” oficial para GissOnline, a combinação de Web Services SOAP municipais, ferramentas de automação RPA e APIs financeiras do OMIE permite montar fluxos automáticos de captura e registro de NFS-e. Toda implementação requer atenção às particularidades municipais como certificados, layout XML e processos específicos.
Fontes
- Documentação GissOnline (manuais ABRASF)
- Portal do desenvolvedor OMIE (lista de APIs)
- Materiais de suporte OMIE (importação de XML)
- Artigos de mercado (Qive) sobre automação de NFS-e