Italo Giurizzato Junior

Boa tarde Claudio, Você pode acrescentar a cidade em questão da mesma forma que as demais que utilizam o mesmo provedor.

Boa tarde Murilo, Tente passar o valor da alíquota dividida por 100, ou seja, em vez de 5 informar 0.05

Boa tarde Roberto, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Duarte, Se todos os fontes estiverem atualizados em vez de atribuir 0120 (por exemplo) ao campo ItemListaServico, basta atribuir 120.

Bom dia Roberto, Na unit pcesS2299, temos a seguinte linha: If (obj.QtdDiasInterm > 0) And (VersaoDF <> ve02_04_01) Then Gerador.wCampo(tcInt, '', 'qtdDiasInterm', 1, 2, 0, obj.QtdDiasInterm); basta fazer a seguinte alteração: If (obj.QtdDiasInterm > 0) And (VersaoDF <> ve02_04_01) Then Gerador.wCampo(tcInt, '', 'qtdDiasInterm', 1, 2, 1, obj.QtdDiasInterm); Alterando o valor do parâmetro de zero para 1, instrui o wCampo a gerar a tag mesmo que o seu valor seja zero. Faça essa alteração e faça novos testes. Fico no aguardo de um retorno.

Bom dia Élviro, A unit pcnRetConsStatServBPe não tem nada haver com o CT-e, veja que ela se refere ao retorno da consulta ao status de serviço do BPe. Essa unit não existe mais, pois essa unit foi substituída pela pcnRetConsStatServ que se encontra na pasta: ...\Fontes\PCNComum Quanto ao erro apresentado na imagem, me diga uma coisa, você esta emitindo um CT-e Normal ou de Complemento de Valores? Veja que esta aparecendo na mensagem de erro de validação: <infCteComp> esse grupo possui uma tag chamada chCTe que deve conter a chave do CT-e a ser complementado. Se não se trata de um CT-e de Complemento de Valores o valor correto a ser informado em tpCTe é tcNormal.

Boa tarde Élviro, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 deixando marcado a opção para apagar os arquivos antigos?

Boa tarde a todos, Conforme consta na Nota Técnica 2018/005 versão 1.30 (disponível na Biblioteca ACBr) as alterações referentes aos grupos de Retirada e Entrega que entrará em vigor no ambiente de produção agora dia 07/05/2019. Alterações no grupo Retirada As alterações se referem aos campos que estão destacados em amarelo, notem que todos eles são opcionais, isso significa que se eles não forem gerados não vai ocorrer nenhum problema, ou seja, a nota vai ser autorizada pela SEFAZ. Como é de costume no componente ACBrNFe esses novos campos estão com a mesma grafia apresentada na Nota Técnica. Observação importante, não devemos gerar o XML com esses novos campos e enviar para o ambiente de produção, pois este só estará apto a partir do dia 07/05/2019, mas nada impede de gerar e enviar para o ambiente de homologação, pois esse já esta aceitando o XML com os novos campos. Alterações no grupo Entrega Idem ao grupo de Retirada. Fragmento do XML com todos os campos de entrega informados: Para quem utiliza o ACBrMonitorPlus, abaixo as alterações em negrito na seções [Retirada] e [Entrega]: [Retirada] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= [Entrega] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= O ACBrMonitorPLUS SAC já esta preparado para gerar o XML com os novos campos, mas vale reforçar mais uma vez que a SEFAZ só vai aceitar esse novos campos no ambiente de produção a partir do dia 07/05/2019. Você pode baixar a versão atualizada do ACBrMonitorPLUS SAC em:

Bom dia Kartter, Sim, se o XML não estiver assinado ao tentar validar vai ocorrer erro de validação acusando a falta do grupo <Signature> que contem a assinatura digital.

Bom dia Everton, Favor atualizar os fontes e faça novos testes.

Bom dia Michele, Segue em anexo. pnfsNFSeW_ISSDSF.pas

Bom dia, Favor atualizar os fontes e faça novos testes.

Bom dia, Estou checando como deve ser montado o soap de consulta no caso de consulta por período.

Boa tarde a todos, Eu até poderia criar uma propriedade de configuração, para definir se deseja assinar ou não o XML. Mas se o desenvolvedor configurar para não assinar, não será possível validar o XML antes dele ser enviando para a outra empresa. Logo essa empresa poderá receber um XML e ao assinar e validar para o envio, este poderá não ocorrer pois o XML contem informações que deixam o XML invalido.

Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.

Bom dia Adilson, Ocorreram diversas alterações nos fontes, favor atualizar os fontes e faça novos testes. Fiz um teste com o seu XML e foi mostrado: Incentivador Cultural: Não

Bom dia, Muito obrigado pela colaboração, enviei para o repositório com uma pequena alteração. Favor atualizar os fontes e refaça os testes.

Bom dia Almir, Até onde sei a cidade de Jaguariúna contratou o provedor Giss. O componente já tem esse provedor implementado, sugiro que utilize o programa exemplo do componente ACBrNFSe para realizar os testes.

Bom dia acg.net, Muito obrigado pela colaboração, já se encontra no repositório.

Bom dia Michele, Fiz uma alteração na unit responsável por gerar o XML, acredito que vá resolver o problema, ainda hoje estarei enviando para o repositório.

Boa tarde Kartter, Eu penso em uma solução diferente. Cada setor alimenta o banco de dados com as informações dos eventos que devem ser gerados e enviados, cada evento teria uma tabela. O setor responsável pelo envio, busca no banco de dados as informações desses eventos que ainda não foram enviados. Gera, assina, valida e envia, por fim atualiza as tabelas "setando" um ou mais campos, para indicar que o evento foi enviado.

Boa tarde Junior, Se não me falha a memória o componente não esta preparado corretamente para realizar consultar por período no caso da NFS-e de São Paulo.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Michele, Apesar de existir as duas opções (Paisagem e Retrato) o DAMDFE em Forte só tem a opção Retrato. Caso queira colaborar com o projeto fazendo o DAMDFE no modo Paisagem para o Fortes, ficaremos agradecidos.