Italo Giurizzato Junior

Bom dia Camilo, Tenha em mente o seguinte: As rotinas responsáveis por assinar, validar estabelecer a conexão com a SEFAZ, enviar, obter o retorno é única, ou seja, a rotina que assina o XML da NF-e é exatamente a mesma que assina os demais DF-e. Outra coisa, acredito que hoje nenhuma SEFAZ-Autorizadora aceita a criptografia diferente de TLS 1.2, sendo assim o valor de SSLType tem que ser TL_TLS1_2 e o valor de SSLLib não pode ser libCapicom uma vez que este não suporta o TLS 1.2 Se o certificado digital for A1, você pode usar o libOpenSSL, desta forma tanto faz se o Windows esta atualizado ou não. Não misture os schemas da NF-e com do CT-e e com do MDF-e, tenha uma pasta de schemas para cada DF-e que a sua aplicação emite. As versões vigentes da NF-e/NFC-e é 4.00 do CT-e e MDF-e é 3.00 Antes de iniciar a implementar qualquer DF-e ou outra funcionalidade como por exemplo emissão de boleto usando o ACBrBoleto, procure sempre fazer testes com os programas exemplos. Temos um programa exemplo para cada componente ACBr. Além do componente, o programa exemplo é o que existe de comum entre nós. Como o Juliomar deixou claro, não conhecemos a sua aplicação não sabemos como você esta implementado. Se no programa exemplo funciona, você precisa estudar a rotina de configuração do componente no programa exemplo para saber o que esta faltando na rotina de configuração da sua aplicação. Espero ter ajudado.

Bom dia Hélio, Existem empresas que pedem aos seus fornecedores que informe o numero do pedido de compra na nota. Por exemplo a Empresa X emite um pedido de compra de numero 1500 para o fornecedor Y, no pedido existe uma recomendação que o numero do pedido seja informado na nota. No layout do XML da NF-e temos os seguintes campos para esse fim: xPed - Número do Pedido de Compra (Informação de interesse do emissor para controle do B2B). nItemPed - Item do Pedido de Compra (Informação de interesse do emissor para controle do B2B). Suponha que no pedido de numero 1500 tenha 5 itens, como os campos acima fazem parte do detalhamento dos itens da nota, logo em xPed informo 1500 e em nItemPed informo o numero do item do pedido que se refere ao item da nota. Uma vez que os itens contidos na nota podem não estar na mesma ordem que se encontram no pedido, ou até mesmo uma nota pode conter itens de vários pedidos de compra. É importante ressaltar que a Empresa deve informar de forma clara e precisa como deseja que o numero do pedido seja informado em xPed, visto que este campo é do tipo caractere e pode ter até 15 caracteres.

Bom dia Rogério, Ao carregar o XML de uma nota usando o método LoadFromFile as propriedades que representam as informações da nota são carregadas. No que diz respeito aos itens temos por exemplo: ACBrNFe1.NotasFiscais.Items[0].NFe.Det.Items[ x ].Prod.vProd Onde "x" varia de zero até a quantidade de itens -1 e vProd temos o valor do produto (quantidade * valor unitário). É importante que você tenha em mãos o manual da NF-e que contem o layout do XML para saber os demais campos. Detalhe importante a nomenclatura usada no componente é a mesma do manual. Na linha abaixo estou lendo o valor do desconto do item "x" e armazenando na variável DescontoDoItem: DescontoDoItem := ACBrNFe1.NotasFiscais.Items[0].NFe.Det.Items[ x ].Prod.vDesc; Na linha abaixo estou atribuindo um novo valor para o desconto do item "x": ACBrNFe1.NotasFiscais.Items[0].NFe.Det.Items[ x ].Prod.vDesc := 0; Fácil, não acha? Desta forma eu consigo ler todas as informações e fazer as alterações que eu julgar necessário. Outro exemplo agora com o total do desconto: DescontoTotal := ACBrNFe1.NotasFiscais.Items[0].NFe.Total.ICMSTot.vDesc; ACBrNFe1.NotasFiscais.Items[0].NFe.Total.ICMSTot.vDesc := 0; Observação: como estou carregando uma nota por vez e antes de carregar uma nota é executado: ACBrNFe1.NotasFiscais.Clear; O índice do primeiro Items sempre vai ser zero. Feita as alterações basta salvar o XML novamente de preferencia com outro nome usando o método GravarXML que você já conhece. No meu entendimento você esta fazendo uma tempestade em um copo d'água por algo muito simples.

Alessandro, Ontem fiz uma alteração em dois fontes do CIOT no que diz respeito a tag EntregaDocumentacao. Me parece que em ambiente de homologação essa tag não deve ser gerada, sendo assim ao alimentar esse campo devemos atribuir o valor edNenhum.

Heronim, Favor trocar os schemas por esses em anexos e faça novos testes. nfse.xsd nfse-v11.xsd

Bom dia Heronim, Estou achando que o schema desse provedor tem alguma coisa errada, vou verificar.

Bom dia Rodrigo, Enquanto não funcionar no programa exemplo, esqueça o seu programa. Configure corretamente o programa exemplo, com os dados do emitente, certificado digital, etc e faça os testes. Ative a opção para salvar os arquivos Soap, com esses arquivos salvos é possível descobrir o porque dessas telas em branco.

Bom dia Alessandro, Porque o arquivo XML de envio esta sendo salvo como TXT? Você esta armazenando o XML no banco de dados? Você esta realizando os testes, usando o programa exemplo do componente? O XML que você anexou aparentemente esta correto. Esta com todos os fontes de todas as pastas atualizados?

Boa tarde André, Muito obrigado pela informação, assim que possível vou fazer a alteração no arquivo INI do provedor e enviar para o repositório.

Boa tarde Maiquel, Testou os 3 métodos de envio? Fez testes também em ambiente de produção? Pois tem provedor que esquece de deixar o ambiente de homologação em perfeitas condições de uso.

Boa tarde, Vou analisar o que você fez, assim que possível darei um retorno. Desde já muito obrigado pela colaboração.

Bom dia Eduardo, Esse provedor possui um layout próprio é preciso verificar se a rotina que faz a leitura do XML já esta preparada para ler esse layout. Se não estiver vai ser necessário fazer as alterações necessárias. Caso queira contribuir com o projeto, fique a vontade.

Boa tarde Carlos, Se para esse provedor se faz necessário ter uma terceira assinatura no que se refere a Substituição de NFSe, teremos que fazer uma alteração no componente, pois ele não contempla essa terceira assinatura. Uma vez que esse provedor é o primeiro a requerer isso.

Boa tarde Stainle, Com o programa exemplo também ocorre o mesmo problema? Se não ocorre, a dica é estudar a rotina que configura o componente do programa exemplo.

Boa tarde Rogério, Você pode usar o ACBrNFe para ler o XML da nota, fazer as alterações que deseja e gerar o XML novamente. Mas esse XML alterado não tem nenhuma validade jurídica, uma vez que ele não condiz com a verdade, ou seja, não é o mesmo que foi enviado para a SEFAZ e por esta autorizado.

Boa tarde Rodrigo, Anexa um print da tela de configuração do certificado, e do erro que esta ocorrendo.

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

Boa tarde Rejane, Já enviei as duas unit para o repositório. Muito obrigado pelos testes.

Luiz, Segundo o manual do BP-e: Emitente é quem emitiu o bilhete, portanto o CNPJ tem que ser o mesmo do certificado digital. Por outro lado o grupo Agencia que é opcional é utilizando para informar os dados da agencia / preposto / terceiro que comercializou o BP-e. Um outro teste que pode ser feito é: O terceiro é de GO, então os dados dele vão ser informados no grupo <agencia>. Ao configurar o componente devemos informar que a UF é GO. Como vai ser utilizado o certificado da Empresa que é de MT, então devemos informar os seus dados no grupo <emit> Ao configurar o componente devemos informar o certificado da Empresa de MT. Ao alimentar os campos do grupo <ide> devemos informar: cUF=52(GO) e UFIni=GO

Por favor, faça mais um teste agora, mantenha a unit que enviei antes e a orientação no que diz respeito a alimentação do campo. E troca essa outra unit em anexo. pcnCIOTW_eFrete.pas A tag só vai ser gerada se o valor de EntregaDocumentacao for diferente de edNenhum.

Heronim, Se você comparar o grupo Signature do exemplo deles com qualquer DF-e (NF-e, CT-e, MDF-e, BP-e) e várias NFS-e que devemos assinar o RPS e ou o Lote vai perceber o seguinte: 1. No exemplo deles o grupo Signature (grupo, subgrupo e elementos) contem o prefixo "ds", que normalmente não é utilizado. 2. Dentro do grupo Transforms existe 3 algoritmos de transformação, sendo que normalmente é utilizado somente 2. 3. Dentro do grupo KeyInfo consta o grupo KeyValue, sendo que normalmente esse grupo não é gerado. Tudo isso e muito mais pode até estar previsto na documentação do Signature, mas repito, normalmente não é utilizado. Podemos concluir seguinte: 1. Esse provedor sabe das coisas, já a SEFAZ e seu grupo XML não conhecem a fundo como se deve gerar a assinatura no XML. 2. Esse provedor é um mala que só quer ser diferente dos demais.

Nilton, Já foi feito a correção, agora é só esperar o pessoal liberar uma nova versão do Monitor.

Bom dia Nilton, Muito obrigado pelo alerta, vamos verificar e fazer as devidas correções.

Rodrigo, Você esta fazendo os testes com o programa exemplo do componente? Se sim, ao selecionar a cidade esta selecionando a pasta de Schemas: SmarAPDABRASF ?

Rejane, Troque a unit por essa outra em anexo. pcnConversaoCIOT.pas Ao alimentar o componente atribua o valor edNenhum ao campo EntregaDocumentacao. É para gerar a tag vazia, vamos ver se vai ser aceito.