Diego Foliene

Boa tarde. Não sei se entendi bem. Fora a adição dos CSTs monofásicos e a geração de seus respectivos grupos, o processo de geração do XML deve seguir a mesma regra. Além disso, se o cProdANP, não está na tabela, entã o não tem os grupos de tributação monofásica, vide: Você está tentando emitir uma nota com CSOSN 500 e está recebendo rejeição?

Boa tarde! Na Rev-30232, foi removido o site de Colatina que estava fixo.

Se possível, por favor, disponibilize o arquivo XML que está usando para testes. Se julgar que o mesmo tenha informações sensíveis e não possa ser anexado diretamente aqui. Envie para [email protected] com o link do tópico no corpo do e-mail, para posterior identificação.

O ACBrMonitor e a ACBrLib criptografam no INI as informações de senha. No caso da lib, você não pode editar e inserir a senha manualmente no arquivo ini, você precisa usar o método NFE_ConfigGravarValor. Você fez este processo?

Veja o ConfigAssinar. Você precisa de um certificado.

Bom dia! A princípio, são essas mesmo. Apenas para confirmar, você as escolheu seguindo a mesma arquitetura da LibNFe, certo? Qual é o provedor de e-mail do rementente? Neste tópico aqui, tem algumas configurações por provedor:

Bom dia! Este campo no layout da ABRASF faz parte do grupo tcInfDeclaracaoPrestacaoServico cuja descrição é: "Representa dados da declaração do prestador do serviço". A descrição do campo em específico é apenas: "Identificação do regime especial de tributação". Analisando os valores que esse campo pode assumir e a descrição do mesmo, a conclusão parece ser essa mesmo, do regime da empresa. Ainda assim, recomendo fortemente, que você consulte seu departamento fiscal ou contador de confiança para buscar orientação de como preencher corretamente para que não sobre problemas para você futuramente. Sim, é possível enviar mais de um serviço para o provedor IPM, desde que seja nas versões 1.00 ou 1.01 que tem layout próprio. Os campos CodServ e CodLCServ não são usados pelo provedor IPM. Na rotina de geração do XML, o mais próximo disso, seria o ItemListaServico e o CodigoCNAE. O ItemListaServico, de acordo com o manual do IPM (disponível AQUI) é o "Código do subitem da lista de serviços em conformidade com a Lei complementar 116/2003". Consulte seu departamento fiscal ou contador de confiança para saber qual é o valor que deve preencher em ambas as propriedades. Apenas o método ACBrNFSeX.Emitir vai enviar o XML do RPS para o web service(considerando que estamos falando somente do envio do RPS para ser convertido em NFSe). Você não precisa rodar o método GerarNFSe, porque ao chamar o GravarXML, se o XML do RPS estiver vazio, o componente gera automaticamente. Uma forma de você obter o XML do lote de RPS é usando o método ACBrNFSeX.GerarLote, conforme comentário retirado do programa exemplo: Se você não quer que seja gerado o arquivo(tanto no GravarXML quanto no GerarLote vai criar um arquivo XML para você), então pode usar o GerarNFSe e pegar o valor da XmlRPS. Sim, é isso mesmo, o XmlNFSe vai armazenar o XML da mesma, quando devolvido no retorno do webservice. XmlEspelho é algo específico para o provedor SigISS A propriedade Situacao é usada apenas pelo provedor AssessorPublico, conforme comentário no programa exemplo. Existem outros provedores que tem uma tag <Situacao> no XML de envio, mas ela é preenchida usando outras propriedades. A propriedade TipoRecolhimento também é específica para alguns provedores. Os valores que podem ser assumidos por essa propriedade são: TSituacaoTrib = (tsTributadaNoPrestador, tsTibutadaNoTomador, tsIsenta, tsImune, tsNaoTributada, tsFixo, tsOutroMunicipio); Recomendo que permita ser configurável, pois se engessar um único valor e no futuro algum cliente tiver rejeição pelo tipo de dado estar incorreto, será preciso apenas alterar no cadastro. Retirado do padrão ABRASF(pode variar em provedores de layout próprio). DataEmissaoRPS: Dia, mês e ano da prestação de serviço. DataEmissao: Data de Emissão do Documento Fiscal. Competência: Data da competência do serviço.

Tópico fechado por falta de retorno do usuário

Tópico fechado por falta de retorno do usuário

Bom dia! Pedi a equipe responsável se é possível gerar uma nova compilação da Lib para que você possa testar não só esta, mas as alterações de outros tópicos também.

Bom dia! Contribuição enviada ao SVN na Rev-30292

Criado em nosso backlog a #TK-4312 para a implementação dos campos

Bom dia! Objetivo Essa nota técnica modifica o retorno do serviço de consulta situação do MDFe para os modais rodoviário e ferroviário. O objetivo dessa mudança é disponibilizar o número do protocolo e data da disponibilização do MDFe para geração do DTe pela InfraSA(Governo Federal). Datas Implantação Homologação: 09/2023 Implantação Produção: 09/2023 Alterações Os seguintes campos foram adicionados no layout da mensagem de retorno: Alterações no ACBr Será necessário alteração nas classes do ACBr para capturar a informação dos novos campos devolvidos na resposta. Consequentemente, novas compilações da Lib e do Monitor serão necessárias. Leia a Nota Técnica na integra AQUI. Mais informações sobre o DT-e no tópico:

Não sei se está relacionado com a rejeição que está recebendo, mas você alimentou o campo receita com o valor 100102. No portal do GNRe, na lista de campos Extras, ele indica a receita 100099.

Boa tarde! Você não quer que seja adicionado a informação do protocolo de autorização no XML original ao consultar, é isso? Se for, tente usar a consulta por chave de acesso ao invés de passando o arquivo.

Boa tarde! Por volta das 15:33, começamos a receber no canal #sefaz em nossa comunidade do Discord, relatos de instabilidade para emitir NFe para a Sefaz de São Paulo. Conferindo no DownDetector, é possível observar que por volta das 15:00 o número de relatos de problema aumentou exponencialmente. Não há contingência ativada até a publicação deste tópico.

Boa tarde! Mais uma vez, muito obrigado pela contribuição. Enviei a mesma ao SVN na Rev-30288

Em minha análise inicial, seria necessidade de alteração no fonte mesmo. Caso queria, tenha a disponibilidade, pode analisar os fontes e o manual e realizar a implementação. Depois anexa aqui, como uma sugestão de contribuição. Do contrário, seria questão de aguardar um parecer do consultor responsável pela TK mesmo.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Bom dia! Conferindo no seu arquivo TXT, o campo IndIEToma, está na seção errada. Ele está em : Quando na verdade deveria estar em : Vide Modelo CTe.INI

Não há "bala de prata", mas de acordo com relatos, uma possível solução para o problema de acordo com relatos, é marcar a seguinte opção:

Bom dia! Não tinha na rotina de geração do INI do componente nativo os grupos citados, por isso que o método CTe.ObterIni não trazia a informação. Adicionado e enviado ao SVN na Rev-30284. Mais uma vez, muito obrigado pelas contribuição nas classes C#, as alterações nas classes C# foram enviadas ao SVN na Rev-30285

Bom dia! Por volta das 16:06 do dia 10/08/2023, começamos a receber relatos de problemas ao emitir NF-e para múltiplas Sefaz. Todos os relatos relatavam estar recebendo: Ao tentar emitir NF-e. A Lista de Certificados Revogados (LCR), conforme o nome diz, é uma lista que contém certificados que foram revogados e não devem ser considerados válidos. Toda vez que a Sefaz recebe um Documento Fiscal Eletrônico, ela consulta essa LCR para verificar se deve aceitar o certificado que fez a assinatura. Quando ocorre a rejeição 296, a Sefaz não está conseguindo acessar essa lista. Nesse caso, o emissor pode escolher aguardar e tentar emitir a NFe novamente posteriormente ou entrar em contato com a certificadora ou a Sefaz para notificá-los do problema.

Bom dia! Se você conferir no manual que temos disponível para o Bradesco aqui, e até mesmo no layout base da Febraban que tem aqui. É possível observar que tem um campo de Ocorrência para o Header do Lote(Registro1), o segmento propriamente dito e o Trailer do Lote(Registro 5). Seu problema acontece porque o PagFor atualmente tenta ler a ocorrência no segmento e no arquivo, ela veio no header do lote. Criada a #TK-4307 para análise do caso e parecer do consultor responsável.

Bom dia! Seus fontes estão atualizados? Teoricamente isso foi resolvido na Revision-30250