Fornecedor Nota Digital

Regra geral de negócio

Este fornecedor utiliza o padrão ABRASF 2.0 com algumas particularidades:

1. suporta a emissão de RPS em lote. Porém, existe uma resalva na emissão de NFS-e em lote em relação as rejeições: ao enviar um lote de RPS o web service de consulta retorna as rejeições para cada RPS do lote de forma sequencial e sem nenhuma identificação de qual RPS pertence a rejeição. Isso faz com que todas os RPS de um lote apresentem rejeição de todos os RPS desse lote na tela de eventos;
2. utiliza certificado digital;
3. exige que os RPS tenham a série 99. Para evitar inconsistências de informações, o eDocs envia para a prefeitura a série do arquivo XML de entrada. Caso seja informada uma série diferente de 99 a prefeitura retorna uma rejeição informando o problema;
4. não suporta emissão de RPS para tomadores do exterior. Ao enviar um RPS onde o tomador tem o estado EX __ como informado no manual, o sistema da prefeitura gera uma rejeição informando que esse estado não existe na base de dados da prefeitura;
5. as tags referentes ao cancelamento por substituição, do grupo <RpsSubstituido>, não são enviadas, pois após emitir um RPS contendo essa tag e realizar a consulta da nota substituída é retornado um java.lang.NullPointerException no web service de consulta;
6. o grupo <Contato> quando informado no arquivo XML, deve ser informado de forma completa. Ou seja, se for informado o Telefone do Contato do Tomador também deve ser informado o E-mail. Se isso não for obedecido, o arquivo XML é rejeitado pela prefeitura com o erro E999 - Ocorreu um erro inesperado;
7. caso não seja informado o número do endereço do tomador no XML de entrada o eDocs enviará esse campo com o valor 0. Isso porque, se não for informado o número o sistema da prefeitura retorna o erro E999;
8. quando a tag <IncentivadorCultural> não estiver informada no arquivo XML ela será enviada com o valor 0, mesmo que o Manual indique que esta tag não deve ser enviada. Isso porque, o sistema do fornecedor retorna o erro E999 quando ela não é enviada;
9. o web service do fornecedor já possui o XSD do arquivo XML imbutido no arquivo de definição do web service (WSDL). Com isso, o arquivo XML não é montado dentro do sistema para ser enviado ao web service, o SOAP faz essa função com base em um objeto de memória. O log de XML pode não ser exatamente o que será enviado para o web service, isso depende de como o SOAP irá serializar o objeto de envio;

10. possui a seguinte regra para geração da tag <RegimeTributacao>:

11. a tag <DddTelefone> do modelo do fornecedor não é gerada pelo ERP, e quando não é enviada o arquivo XML é rejeitado com o erro E999. No arquivo XML de entrada do ERP é possível informar o DDD junto ao valor da tag <Telefone>. Para que não seja necessário informar o DDD manualmente, o eDocs verificada se existe o DDD do telefone informado no arquivo XML de entrada, se existir ele é gerado na tag, caso contrário ela é gerada com o valor 00;
12. caso seja enviado dois RPS em um único lote para o sistema da prefeitura e ocorra problemas no envio, sendo necessário cancelar os RPS via eDocs, o web service do fornecedor retorna que o primeiro RPS não existe na base de dados. Nessa situação é necessário cancelar a NFS-e no site da prefeitura.
13. a tag <TipoLogradouro> não é gerada pelo ERP, pois entende-se que será informado direto no Logradouro o seu tipo (exemplo: rua, avenida, quadra e etc.). Como a tag obriga que seja informado um de vários valores fixos que a prefeitura define, será enviada sempre com o valor Rua;
14. o leiaute de envio do número do RPS exige 15 caracteres, sendo os 4 primeiro o ano + 11 caracteres que compõe o número do RPS completados com zeros a esquerda e que seja sequencial. No Gestão Empresarial | ERP o usuário deve informar apenas o número do RPS sequencial do último RPS emitido, pois no envio do RPS para a prefeitura o eDocs formata este número de acordo com o leiaute exigido.
    Exemplo: o número do RPS no ERP é 37. No envio da tag <Numero>, do grupo <IdentificacaoRps>, o envia o número 201700000000037.

Regra específica por município

Não possui regra específica por município.

Parâmetros por município

Não possui parâmetro por município.