Painel de líderes

Correção no SVN.

Substitua o arquivo anexo, recompile o ACBr e tente novamente. pcnNFeW.pas

Juliomar, Obrigado pela resposta. De fato, troquei o componente pelo DANFEFR e configurei com o caminho do FastFile e funcionou. A Danfe está sendo impressa. Mais uma vez obrigado, Airton

Boa tarde Senhores. Fui realizar um teste no componente no IBPTTax hoje porém o caminho do webservice difere do caminho apresentado na documentação. Realizei o ajuste. Segue em anexo a unit. Grato ACBrIBPTax.pas

No DANFE em Fortes você pode escolher quais informações imprimir.

Estava com o mesmo erro para emitir NFCe e verifiquei que os endereços para a SEFAZ do MS não estavam configurados. Segue os endereços e o arquivo ini e res. NfeAutorizacao_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeAutorizacao4 NFeRetAutorizacao_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeRetAutorizacao4 NfeConsultaProtocolo_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeConsultaProtocolo4 NfeInutilizacao_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeInutilizacao4 NfeStatusServico_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeStatusServico4 RecepcaoEvento_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/NFeRecepcaoEvento4 NfeConsultaCadastro_4.00=https://homologacao.nfce.fazenda.ms.gov.br/ws/CadConsultaCadastro4 ACBrNFeServicos.ini ACBrNFeServicos.res

Boa Tarde, estamos analisando para subir as alterações para o SVN, mas não ficou claro a necessidade de implementar a função (CodOcorrenciaToTipoRemessa) para o Banco Caixa visto que não existe chamada para essa função na classe...

Daniel, é exatamente isso que estou dizendo. Eu usava a imagem na NF-e, porque a NFC-e eu imprimia com outra rotina que fiz em xHarbour. Aí quando passei a usar a impressão da NFC-e pelo Monitor eu vi que ajustou, porque não tinha como eu usar outra imagem apenas para a NFC-e. Só que a mesma imagem é impressa no cupom do SAT, mas sem redimensionar, no DANFE da NFC-e redimensiona. A imagem que uso para NF-e fica boa na NFC-e, mas não fica no cupom do SAT, mas agora como separou da NF-e eu posso redimensionar. Mas valeu a dica, eu redimensionei no Photoshop e ficou ótimo. De fato bem mais leve. As medidas da imagem ficaram 4cm de largura por 1,5 cm de altura e 200 pixeis. Muito obrigado.

NT 2016.002 v1.20 https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=20k0jfiSgtk=

Aparentemente você tem uma cópia de ACBrUtil, em alguma de suas pastas, e ela está sendo usada em detrimento da Unit da ACBrComum

Você precisa copiar as DLLs da MinGW, leia o tópico:

https://www.example-code.com/delphiDll/crypt_hash_algorithms.asp Quem sabe uma ideia para a SHA-256

Correção no SVN e disponibilizada na versão semanal do SAC:

Bom dia no svn as correções. Obrigado pela colaboração e testes.

então acho que deve de pedir maiores informações pois o que está parecendo é que ele está falando do sped ou de nota de acompanhamento de cupom. e não de ECF em si.

Bom dia, Seguem mais dois ajustes (Um deles é no ECD): 1. ECF Y640, mesma situação dos itens do post anterior procedure TBloco_Y.WriteRegistroY640; LFill(COND_DECL, 1) 2. ECD K001 O validador acusa que o registro K001 é inválido para o tipo de escrituração quando Registro0000.IND_ESC_CONS = "N". Adicionado tratamento para gerá-lo apenas quando Registro0000.IND_ESC_CONS também estiver preenchido com "S". Abraççç, Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho ACBr002.rar

somente agora notei que não compreendi corretamente a sua pergunta... A ideia é saber qual é a marca/modelo do SAT que está do outro lado, correto ? Realmente não tem como... isso poderia/deveria ter sido previsto, no retorno do comando ConsultarStatusOperacional... mas o fisco não implementou... (veja página 224 da Especificação Técnica do SAT) Humm.. talvez pelo número de série, poderíamos ter uma tabela de fabricantes:

@gutembergscosta Use a função de conversão: CST_IPI := CstIpiToStr(stipiEntradaIsenta) . foi acrecentado o prefixo "st" e agora se tornou um enumerador em vez de uma constante. faça isso para as demais que dará certo.

São Paulo ainda não divulgou os endereços. Apesar de ser possível deduzir os endereços baseados nos endereços atuais + os novos nomes, os webservices ainda não estão compatíveis com as alterações previstas. Por exemplo, o Status de Serviço para a versão 4.0 pode ser acessado através do endereço https://homologacao.nfe.fazenda.sp.gov.br/ws/NfeStatusServico4.asmx?WSDL mas o soapAction ainda está no padrão antigo, <soap12:operation soapAction="http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2/nfeStatusServicoNF" style="document"/> onde está o 2 em destaque, deveria estar 4 e por este motivo não irá funcionar com os fontes atuais do componente.

Não faço parte do Governo, e não sou fabricante de SAT... mas acho que o SAT é uma ideia infinitamente melhor e mais robusta do que a NFCe... Nosso software atende PAF-ECF, NFCe e SAT... ( www.djpdv.com.br ) e minha opinião, é que a NFCe é um "filho mal parido da NFe"... Autenticação online, para varejo ?? Resultado: fila nos caixas dependendo do horário... Nosso software faz o tratamento automático da entrada e saída de contingência, trabalha em Background na transmissão da fila do OffLine, e na resolução de outras pendencias... Muita da inspiração que tivemos na construção de nosso módulo emissor de Documentos Fiscais, veio da observação do funcionamento do SAT. Mas mesmo assim, nosso suporte, sofre com o NFCe... Cada estado tem uma peculiaridade, a Internet no interior do Pais é intermitente e de qualidade lastimável... então o que podemos observar, é que a experiência de uso do usuário com o SAT, é infinitamente melhor do que do usuário de NFCe... Se o fisco fizesse cumprir o rigor da lei, que obriga a transmissão dos XMLs emitidos em OffLine, em até 24 hs úteis, muitos estabelecimento já teriam fechado as portas... O projeto NFCe é uma péssima ideia para o varejo...mas que está sendo remendada aqui e ali, e vai funcionar aos trancos e barrancos... Sinceramente, o varejo estava bem melhor com os ECFs, do que com a NFCe. O projeto SAT por sua vez... demorou 3 anos para nascer, o fisco de SP fez inúmeras consultas públicas, convocando setores do varejo, fabricantes e Sw.Houses de Automação Comercial. Tudo isso para mitigar os problemas e deixar bem clara as regras e normas de uso. O Fisco foi aberto a sugestões, e criou uma especificação técnica clara, consistente e que funciona... O SAT, passou por um período de ajuste... Alguns fabricantes sofreram até deixar seus Sw.Básicos e DLLs robustos o suficiente para o uso.. O retaguarda do Fisco apresentou inumeradas falhas (reconheço que algumas ocorrem ainda hoje em dia)... Mas hoje, podemos afirmar, que o SAT está muito mais maduro e robusto do que a NFCe... e o que percebemos no uso dos clientes finais, é a filosofia: "Instale e esqueça"... pois depois de instalado o SAT, ele funciona sozinho... Porque vocês acham que SP não permite NFCe off-line ? Alguns estados, já perceberam o grande aumento da sonegação fiscal, quando passaram a permitir: offline + impressora não fiscal nos caixas... (afinal o empresário Brasileiro, não paga imposto só porque que é patriota) Os números falam por si... Quem esteve na última reunião do ENCAT pode presenciar... Atualmente, SP já autorizou mais CFe's (SAT), do que a soma de todas as Unidades Federativas do brasil autorizaram NFCe's. Incluindo nessa conta.. as milhares de NFCe's que o próprio SP emite...

Aqui na empresa, utilizamos o delphi para desenvolver nosso principal produto, um ERP, no entanto, neste ano fizemos uma análise do futuro do mercado de software e temos visto que o visual studio tem agregado uma série de tecnologias até então indisponíveis no delphi, e que, com exceção do Brasil e Russia, o delphi tem perdido força no mundo inteiro, fazendo com que em agumas regiões já não se encontre mão de obra especializada. Por isso vamos desenvolver a solução para NFCe em visual studio e C#. Quando decidimos isto, fizemos uma pesquisa por bibliotecas que já estivessem prontas para tal, e analisamos a UniNfe da Unimake Software, o ACBRNFeMonitor e o projeto Open NFe. No caso da UniNfe, vimos que ela implementa o consumo dos webservices para NF-e, NFC-e, CT-e, MDF-e e NFS-e e faz a Integração ao ERP via arquivos, mas infelizmente não gera o XML e não possui classes para tal. Outro ponto negativo é o fato de ter que persistir arquivos em disco para poder consumir os serviços, o que diminui a eficiência. O ACBRNFeMonitor possui integração via troca de arquivos, como no caso da UniNfe, e via telnet, mas o retorno de alguns serviços deixa a desejar pelo fato de devolver uma resposta em formato diferente dos manuais para aquele serviço. Outro fator é a integração com o C#. Por último o OpenNFe tem um acoplamento forte com o Sql Server, e ainda a forma como foram implementadas as classes não facilita o uso. Basicamente o autor pegou os schemas e importou-os no c#, sem muito tratamento. No meu caso, estou tendo o cuidado de escrever as classes seguindo rigorosamente os manuais disponíveis, inclusive quanto a forma como os serviços são consumidos. Até mesmo os comentários para cada campo disponíveis nos manuais foram adicionados em cada campo de cada classe. Uma coisa que percebi analisando o código do componente do ACBR para NFe é que por conta das limitações do Delphi, o estilo de programação utilizado apresenta risco considerável e dificuldade de manutenibilidade do código. Por exemplo, existe muita, mas muita magic string no código, enquanto no C# o tratamento de XML é nativo via serialização. Em breve postarei mais informações sobre a biblioteca, saudações.

Obrigado por perguntar... ainda não temos.. mas sim, pretendemos implementar isso em breve, (planos trimestrais, semestrais e anual).. além de várias outras melhorias no SAC do ACBr