Francisco IBS

Aparentemente fez o esperado. Agradeço a atenção.

@Juliana Tamizou Realizei mais uns testes e encontrei um problema que essa alteração gerou, ao gerar a linha digitavel. Consultando a documentação do banco ficou confuso o tratamento que deve ser feito: Então por favor não fazer a alteração solicitada a cima. Pode encerrar o Tópico, assim que confirmar a situação com o banco reporto caso haja necessidade de fazer alguma alteração no componente do ACBr. Grato pela atenção e peço desculpas por qualquer transtorno.

Boa Tarde... Utilizando o Banco Cresol notei que a nova classe ACBrBancoCresol esta utilizando o tamanho da carteira da sua antecessora que é 2 casas mas no manual ela é apenas uma, em anexo manual e Unit já com a alteração realizada. ACBrBancoCresol.pas manual_cobrança_integrada_240.pdf

Bom Dia... Esta na mão as alterações para validação e adição ao fonte. Desde já agradeço a atenção. ACBrBancoUnicredES.pas ACBrBoleto.pas

Panda, aparentemente deu boa o Nosso Numero pode ser obtido como necessário. Mas ocorreu outro problema, vou reportar aqui mas se achar necessário que faça outro tópico posso migrar ele. A rotina de verificação se houve erros ou não no retorno na classe padrão verifica de 214 até 223 mas nesse caso a Unicred utiliza os campos 222 até 223 para o "TIPO DE INSTRUÇÃO ORIGEM". Logo no retorno que passei a cima temos 01 nesse campo que segundo o manual é "01 - Remessa". Em resumo o campo com o retorno do motivo de uma rejeição é apenas do 214 até 221:

Bom Dia Panda, baixei as altereções do SVN e ao testar não resolveu o problema. Fazendo a importação do arquivo em anexo "_RetornoTestes.RET" não foi possivel identificar o Nosso numero, com a configuração atual ele pegou apenas os 10 primeiros ZEROS do campo nosso numero. Então alterei a propriedade "ACBrBoleto1.Banco.TamanhoMaximoNossoNum" para 19, conforme o Manual, dessa forma o Nosso Numero foi encontrado mas gerou problema para criar uma Nova remessa. _RetornoTestes.RET

Com a Live ali ficou extremamente claro, Obrigado.

Que a NFCe parece que vai emplacar em SC eu entendo mas assim, são dois tipos de TTD que podem ser escolhidos um com a ECF em contingencia e outro com um futuro "SAT" que será ainda desenvolvido, logo só podemos utilizar 1 dos TTDs disponível o com a ECF, Certo? Se o raciocínio a cima esta certo mesmo que clientes com 20 ECFs possam usar um servidor de contingencia para a impressão em ECF ele vai precisar ficar ao menos com Uma ECF no estabelecimento. Tendo a ECF no estabelecimento vc se encaixa no bloco X e é obrigado a entregar o arquivo do estoque anual, só se escaparia caso fosse uma empresa do Normal que pode fazer a escolha de entregar via o SPED, não? Perdi alguma coisa que a NFCe da forma que esta atualmente permite não fazer envios do bloco X?

No log a cima não esta, mas testei com ele e tive o mesmo resultado.

Estou usando a um tempo já a comunicação via USB que usa a DLL da ECF como túnel. Fiz uns testes de desligar a ecf e ligar novamente para ver se a comunicação seria perdida(como ocorre na Bematech 4200) e notei que ao chamar a função "ACBrECF.Desativar" não é chamada a função da classe "TACBrECFEscECFProtocoloEpsonDLL = class( TACBrECFEscECFProtocolo )". Em anexo o log onde executo o ativa: -- 10/09 14:36:25:170 xEPSON_Serial_Abrir_Porta( 115200, 0 ) -- 10/09 14:36:25:549 Mas o desativar não é executado, debugando ele não é chamado. Mais algum relato de problemas ao desligar e ligar novamente o equipamento com esse novo modo de comunicação? ACBrLog.txt

Resolvido o problema, apesar da mensagem estar repassando o status de que o MFE esta bloqueado por excessivos erros no código de ativação todo o problema se resumiu no numero de sessão, ele estava com 7 dígitos em vez de 6. Com 5 dígitos também ocorre outro erro, então fica a dica. Pode fechar o tópico por favor.

Bom Dia... Estou instalando o meu primeiro MFE em produção no CE e encontrei um problema que não estou enxergando solução. Ao tentar realizar uma venda tenho o retorno "06009|0000|MFE bloqueado, código de ativação incorreto". Tenho o componente ACBrSat dentro da minha aplicação então já revisei a programação tentando encontrar a falta de alguma configuração e até cheguei a por "showmessage" no código de ativação na Unit "ACBrSATMFe_integrador.pas" na função "TACBrSATMFe_integrador_XML.EnviarDadosVenda(" para ter certeza que nesse momento o código de ativação estava correto. Utilizando o SATTest.exe a venda é realizada com sucesso... A baixo o log das 2 aplicações, alguém conseguiria me dar uma dica do que não estou vendo? Note que no Log da minha aplicação antes de gerar a venda usei o comando "ConsultarStatusOperacional" que também utiliza o Código de Ativação e nesse momento ele não retornou que estava incorreto. Fora que foi feita toda a homologação necessária para liberação no SEFAZ e não tive nenhum problema, só que em homologação estava utilizando um TANCA e em produção é um Elgin, algum tipo de parametrização a mais ou diferente de um para outro? ACBrSAT Log Minha Aplicacao.log ACBrSAT Log SATTestes.log

Juliomar só testei no delphi 7 e esta funcionando, lazarus infelizmente não testei. Então Daniel o uso do TFileStream foi para tentar montar o arquivo mais rápido mesmo, pelo que recordo nos testes que fiz deu uma boa diferença para montar ele como TFileStream, inicialmente tinha usado uma TStringList. Com relação a assinatura quando tentei usar pelo ACBR levou 10 min pelo que recordo, dai acabei fazendo a assinatura por "fora" com outra rotina que já existia no meu sistema.

Boa Tarde... Compactei toda a pasta do bloco X que esta em anexo. Primeira mente criei a unit "pcnGeradorBlocoX.pas" que é uma cópia da "pcnGerador.pas" só que modifiquei a classe para usar WideString e TFileStream pois não queria estragar nenhuma outra rotina que já usa ele. Por que "TFileStream" ? Nos testes que fiz foi a forma mais rápida que consegui para criar o arquivo. Unit ACBrBlocoX_WebServices.pas ganhou 2 novas variaveis "SituacaoProcStr" e "Mensagem" para guardar as informações do retorno. Acredito que seja isso, desculpe a demora, como comentei não estou na empresa essa semana. Caso falte algo ou alguem tenha alguma outra sugestão fico aberto a críticas. ACBrBlocoX.rar

Inicialmente quando fiz as alterações tinha uma esperança e pelas conversas no forum que isso seria alterado, mais pelo andar da carruagem creio ser dificil, então por isso não sugeri a alteração no SVN. Não sei como anda o desenvolvimento disso pelos ADM's ou colaboradores que tem acesso ao SVN mais se não tem nenhuma alteração do fonte para isso posso disponibilizar 100problemas o que desenvolvi, só não consigo essa semana só para semana que vem.

Esse foi o entendimento que tive, a única coisa que eu mudaria no que vc falou é a questão de produto com quantidade < 0... pelo que da a entender isso não pode ocorrer, não recordo se vi algum questionamento disso lá no grupo de discussão ou na base de conhecimento do CAF, no endereço http://caf2.sef.sc.gov.br/, acesse a opção ECF, vais encontrar algo, pelo que entendi o cliente deve sempre deixar o estoque 0 ou positivo, no arquivo não deve conter estoque negativo. O que é estranho pq lembro de ter uma flag no xml que diz se o estoque é positivo ou negativo.

Boa Tarde... Semana passada troquei um e-mail com o Bruno Nogueira sobre isso, eu tive um primeiro entendimento errado o correto é: - Qualquer produto com quantidade a cima de 0. - Qualquer produto com movimentação, venda ou entrada. Deve constar no arquivo de estoque.

O componente estava na tela mais não estava selecionado no componente do sat.

Boa Tarde João... Então e tomei a liberdade de fazer algumas alterações no componente para gerar o arquivo já que o estoque já é obrigatório o envio esse mês, precisei alterar a forma que se guardava a informação para gerar o XML(esta usando String se não me engano) e também alterei a forma de se fazer a assinatura, pode se por falta de conhecimento minha do componente mais estava levando bastante tempo. Notei que vc comentou de possuir 120k de produtos, a legislação esta bem "por cima" dando/deixando muitas brechas pela questão do entendimento, pelo que entendi deram liberdade para cada estado criar o seu WS então pensa na confusão que isso vai ficar... Mais em contato com o pessoal técnico que me colocou em contato com o GESAC cosegui esclarecer bastante coisas uma delas é que não é necessário mandar todos os produtos(como me foi exigido na homologação) e sim apenas os que tiveram movimentação(entradas ou saidas) no período. Vou deixar um grupo de discussão administrado pela SEF-SC bem util a baixo, anteriormente deixavam até fazer questionamentos mais hj apenas para atualização de o que esta ocorrendo na parte Técnica do Bloco X. Mais tem algum material de legislação ali já postado tbm: https://groups.google.com/forum/#!forum/sef-sc-siv Nesse grupo de discussão vc vai poder ver que existem questionamentos com relação ao tamanho do arquivo e o pessoal da SEF não parece ter a intenção nenhuma de mudar isso ou a forma que é feita, não que devemos concordar com isso, mais precisamos cumprir as obrigações legais que nos são impostas.

Daniel acho que podemos fechar o Tópico, já saio bastante assunto fora dele mesmo e o que precisava já foi esclarecido: - Rejeição 905 estaria ocorrendo pela falta da tag vDesc no XML. - Essa tag não será gerada caso o valor for 0 já que não é um campo obrigatório. - Esse valor não vai ser alterado no componente pois o mesmo respeita as NT.

Grande chance da SEFAZ não ter atualizado as alterações da NT, por isso vc não estaria tendo a rejeição 905.

Blz @BigWings, pelo que entendi no seu primeiro post: A sugestão seria jogar um 0,01 no valor desconto para que ele seja inserido no XML, certo? R: Alguem do ACBr sabe ou tem algum contato/colaborador que chegou a confirmar se essa validação esta correta(por algum contato com alguma das SEFAZ), já que isso seria um paliativo certo? PS: Particularmente achei mais bonito por o campo como obrigatório no fonte indo 0,00, sei que vou ter que dar manutenção nisso caso ocorra alguma alteração na unit, mas preferi assim. Ao menos até desvendarmos o como isso vai ficar.

Bem ai que esta o problema já que a nota técnica vai de contra a isso, então não da de saber se é um erro deles ou um erro na NT. Como traz a NT 1.60 não obriga nenhum dos campos do "Grupo Fatura", a Regra "Y01-20" meio que vai de contra ao que esta na descriminação do campo... Agora ficamos nessa de se o Estagiário lá só seguio ao pé da letra o que estava descrito na regra ou se esqueceram de alterar a descrição do campo.

Desculpe Wallas, estava testando aqui e tinha alterado o fonte colocando obrigatório o campo, justamente por não ter desconto e quando informado 0 no valor ele não gerava no XML. "Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC);" Então creio que terá que ser tratado diferente esse campo, para mesmo que for 0 ir no XML.

Bom Dia... Realizei uns testes hj pela manha no ambiente de homologação de SC e obtive a rejeição: "905 - Rejeicao: Campos do grupo Fatura nao informados" Indo no site do SEFAZ notei que foi disponibilizado um novo pacote de SCHEMAS onde alteram a TAG vDesc, fica a dica pra quem encontrar o mesmo problema e o pedido para atualizaram no SVN. Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b) http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=CoNA9VIgZ3E=