Padrão DSFNET
Este artigo contempla as particularidades dos padrões:
- DSFNET Abrasf
- DSFNET Sequencial
- DSFNET não sequencial
O padrão exige assinatura do RPS, portanto um certificado digital A1 válido deve obrigatoriamente estar cadastrado na empresa para emissão.
Algumas prefeituras do padrão utilizam método de emissão assíncrono. Desta forma, é necessário aguardar alguns segundos antes da nota ser autorizada. Obs: não é necessário preencher o Tipo de Processamento da empresa como Assíncrono. Pode ser necessário consultar o documento posteriormente para obter o status do processamento (utilize Webhook para receber automaticamente o status do documento).
Envio sequencial
A principal particularidade é que alguns municípios atendidos pelo padrão realizam emissão de RPS de forma sequencial. A autorização dos RPS são sequenciais, ou seja, enquanto houver alguma rejeição as notas posteriores não serão processadas pela prefeitura.
ISS Retido
Não há diferenciação de valor ISS e valor ISS Retido. A prefeitura definirá com base no código de tributação.
Transportadora
Não há grupo de transportadora no preenchimento do RPS. Você pode enviar ao InvoiCy, mas a informação não será enviada no RPS para a prefeitura.
Parcelas
Não há grupo para informar parcelas ou condições de pagamento. Você pode enviar ao InvoiCy, mas a informação não será enviada no RPS para a prefeitura.
Inutilização
Não foi disponibilizado método para inutilizar numeração de RPS não autorizados. Em caso de pulos de numeração, siga a sequência normalmente. RPS rejeitados podem ser enviados com o mesmo número.
Substituição
O padrão disponibiliza método para substituir RPS autorizado. Envie um novo RPS com o grupo de substituição, a prefeitura irá cancelar a NFS-e relacionada ao RPS anterior e emitir uma nova com os dados corretos.
Consulta de notas recebidas
Os municípios disponibilizam consulta de notas recebidas através de API para as empresas que possuem a extensão de Importação de Documentos ativa. Os documentos podem levar alguns dias até aparecerem no InvoiCy, dependendo do intervalo de consultas e também do tempo que a prefeitura leva para sincronizar os documentos.
Consulta de notas emitidas
Os municípios disponibilizam consulta de notas emitidas através de API para as empresas que possuem a extensão de Importação de Documentos ativa. Os documentos podem levar alguns dias até aparecerem no InvoiCy, dependendo do intervalo de consultas e também do tempo que a prefeitura leva para sincronizar os documentos.
Leitura de e-mail
Os layouts de retorno ou exportação de notas da prefeitura foram treinados no sistema para importação de documentos. Quando uma caixa de e-mails cadastrada para leitura recebe um arquivo XML neste formato, o sistema irá validar se a extensão de Importação de Documentos está ativa para um dos envolvidos (prestador, tomador) e importará o documento.
Leitura OCR
Alguns arquivos PDF da DANFSE da nota fiscal gerados pelas prefeituras do padrão foram treinados no sistema para importação de documentos utilizando a técnica de OCR. O arquivo poderá vir por caixa de e-mails ou importação via API/WS e, caso a extensão InvoiCy OCR estiver ativa, o mesmo será importado no sistema. É importante frisar que a leitura de OCR não é 100% precisa, e alguns campos podem ser lidos ou interpretados com informações incorretas.
- Série: Primeiramente, as prefeituras deste padrão sempre utilizam a série com o valor 99. Apenas em situações especiais, com autorização da prefeitura, o prestador poderá informar um valor diferente.
- DDD e Telefone: O de telefone do tomador precisa necessariamente informar o DDD com dois dígitos, obedecendo o modelo 5535354800. O mesmo modelo deverá ser informado no número do telefone no cadastro do prestador. O que ocorre é a exigência da prefeitura em informar um campo com o DDD do tomador e prestador. Neste caso, o InvoiCy NFS-e identifica os dois primeiros dígitos do número como sendo o DDD para enviar à prefeitura, sem que com isso o usuário precise adicionar um novo campo na estrutura do XML.
- Códigos de Municípios: Uma característica que pode trazer dúvidas para os prestadores que já emitem com outras ferramentas ou via sistema online das prefeituras refere-se ao código de município. As prefeituras que adotam o padrão DSFNET utilizam a numeração da Receita Federal (também denominada SIAFI), diferentemente do restante do país. Para utilizar o InvoiCy NFS-e o usuário deverá informar o código IBGE do município do prestador, tomador, e local de prestação do serviço que o sistema converterá automaticamente.
- Intermediários: Apenas as prefeituras de Sorocaba/SP e Campo Grande/MS permitem informar o intermediário do serviço. Neste caso, além de informar o intermediário do serviço, o campo Operação deverá informar o valor Intermediação (J).
- Dedução: As tags
DedCNPJRef,DedCPFRef,DedmNFRef,DedvlTotRefsó deverão ser informadas quando a atividade permitir dedução por materiais (campo = B). - Usuário de autenticação: É necessário preencher o campo Usuário Autenticação na tela de configurações de emissão de NFS-e do painel de controle do InvoiCy, com o CPF/CNPJ de um subusuário que esteja ativo no sistema da prefeitura.
- Estes subusuários podem ser obtidos no sistema da prefeitura através do Menu Minha Empresa > Vincular Subusuários.
- Recomenda-se que o certificado digital contenha o mesmo CPF/CNPJ do subusuário que for selecionado.
- Inscrição Municipal: Conforme o município da empresa poderá variar o tamanho do valor informado no campo Inscrição Municipal. O InvoICy irá preencher com zeros à esquerda caso o tamanho informado for menor do que o exigido para cada cidade.
- Discriminação do Serviço: Para a discriminação se um serviço (tag
ItemDesc), somente é permitido informar 250 caracteres. Caso seja informado uma descrição acima deste limite estipulado, o InvoiCy irá enviar apenas os 250 primeiros caracteres.- Para a discriminação do RPS(tag
Discriminacao), é permitido informar até 1500 caracteres. - Obs.: Caso o RPS possua apenas um item de serviço e não seja informado a tag
ItemDesc, o InvoiCy irá escrever a informação usando a tagDiscriminacao, considerando os primeiros 250 caracteres.
- Para a discriminação do RPS(tag
Cancelamento
No padrão DSFNET mesmo que um RPS seja cancelado, a numeração dos próximos RPSs permanecem de forma sequencial, ou seja, se o RPS 5 for cancelado pelo Prestador, o próximo número a ser enviado será o RPS 6.
Operação
A tag Operacao é obrigatória e deve receber um dos seguintes valores:
A - Sem Dedução
B - Com Dedução/Materiais
C – Imune/Isenta de ISSQN
D – Devolução/Simples Remessa
J – Intemediação